GNOME Bugzilla – Bug 703349
Size calculation does not stop, recursive files/folders item count and filesize resets repeatedly
Last modified: 2015-09-03 13:48:58 UTC
Created attachment 248086 [details] Two sample directory structures triggering a bug When I select multiple objects in Nautilus and open Properties dialog it does not stop total size calculation sometimes and infinitely repeats calculations instead. Software Version: Ubuntu 13.04 with all updates installed. Package: nautilus 1:3.6.3-0ubuntu16 Steps to Reproduce: 1) Unpack example.tar.gz 2) Open Nautilus and navigate to example or example-minimal directory 3) Select all objects (one file and one directory) and open Properties dialog Actual Results: "Contents" field is being recalculated infinitely (in case of example-minimal there are no changes in label but indicator next to it constantly spins and nautilus process wastes CPU time). Expected Results: Total file size in "Contents:" field after size calculation finishes. Links: This bug is already reported on Launchpad several times. Maintainers asked someone having this bug to report it upstream. https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/1131571 https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/1162117 https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/1176368
Same bug on Fedora 19 Gnome 3.8
Created attachment 256877 [details] [review] properties-window: Only perform deep count for directories Prevent the spinner running endlessly when files are selected by only starting the deep count for directories.
Ping. Would it be possible to review this relatively simple patch?
Review of attachment 256877 [details] [review]: Obviously correct, but it'd be good to fix nautilus_file_recompute_deep_counts as well.
Comment on attachment 256877 [details] [review] properties-window: Only perform deep count for directories Attachment 256877 [details] pushed as 1eae084 - properties-window: Only perform deep count for directories
(In reply to comment #4) > Review of attachment 256877 [details] [review]: > > Obviously correct, but it'd be good to fix nautilus_file_recompute_deep_counts > as well. I don't know the code very well, but isn't this done already in deep_count_start() in nautilus_directory_async.c?
(In reply to comment #6) > (In reply to comment #4) > > Review of attachment 256877 [details] [review] [details]: > > > > Obviously correct, but it'd be good to fix nautilus_file_recompute_deep_counts > > as well. > > I don't know the code very well, but isn't this done already in > deep_count_start() in nautilus_directory_async.c? Looks like it, but then why does the spinner never stop? I pushed your patch because it works, but left this open so that someone more familiar with that code might take a look eventually. There's also another call to start_deep_count_for_file() in properties_window_update().
(In reply to comment #7) > > I don't know the code very well, but isn't this done already in > > deep_count_start() in nautilus_directory_async.c? > > Looks like it, but then why does the spinner never stop? I pushed your patch > because it works, but left this open so that someone more familiar with that > code might take a look eventually. Doesn't it stop? It does for me on the test case above.
I meant: why doesn't the spinner stop without your patch. Your patch works fine. My concern is just that if we need to protect the call to deep_count_start() in one location, the other call probably should be protected as well.
*** Bug 721675 has been marked as a duplicate of this bug. ***
*** Bug 729368 has been marked as a duplicate of this bug. ***
Cosimo took a look at this recently for Bug #698895, so I think this can be closed.
Unfortunately this doesn't seem properly fixed yet or has regressed (nautilus 3.14.2). The examples work fine but occasionally I stumble upon folders that still trigger it. Steps to Reproduce: 1) download some big tarbal (one with lots of files and dirs seems to trigger it, e.g. https://www.kernel.org/pub/linux/kernel/v3.x/linux-3.19.2.tar.xz). 2) extract it and enter the folder with the kernel. 3) Select all files and folders and open Properties dialog. P.S. I'm not sure whether I should mention this here or open another bug for it (it seems like it is the very same bug so I just went ahead).
I can also reproduce the size calculation reset loop, but not with the examples in comment 0. So, yes, this particular case is fixed, bug other examples still hit the bug. See bug 754505, recently reported.