After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 773416 - Nautilus needs to be restarted to record top level "item" changes not done through Nautilus
Nautilus needs to be restarted to record top level "item" changes not done th...
Status: RESOLVED DUPLICATE of bug 768455
Product: nautilus
Classification: Core
Component: general
3.22.x
Other Linux
: Normal normal
: ---
Assigned To: Nautilus Maintainers
Nautilus Maintainers
Depends on:
Blocks:
 
 
Reported: 2016-10-24 11:02 UTC by Inactive account
Modified: 2016-10-24 12:06 UTC
See Also:
GNOME target: ---
GNOME version: 3.21/3.22



Description Inactive account 2016-10-24 11:02:44 UTC
I have recently found that after upgrading from Ubuntu GNOME 16.04.1 with GNOME 3.20 to Ubuntu GNOME 16.10 with GNOME 3.22 that in Nautilus the little indicator of how many "items" there are in the top level of the selected directory does not get updated when Nautilus is open if another program creates an item in the directory, though Nautilus will update the indicator if it makes the changes.

For instance I launched Nautilus, then I created a directory which had no items currently in it so it was displayed as ""test" selected (containing 0 item)". Then I opened Terminal, cded into the right directory, and executed "touch t.txt". The indicator in Nautilus, no matter what I did, whether I went into the folder and saw that the item was there, or I clicked "Properties" in the right-click menu and got an accurate result, it didn't show the update in items count in the little indicator in the bottom-right-hand corner of Nautilus until I restarted Nautilus.

This is the same for creating directories in the directory, not just files.

I initially reported this issue here: https://bugs.launchpad.net/ubuntu-gnome/+bug/1636144 But thought I should also do so upstream. The downstream bug report includes more system and application information (gathered by apport).
Comment 1 Carlos Soriano 2016-10-24 11:38:39 UTC
Thanks for the report.

This would require monitoring more than just the current file, which is not doable with the Linux kernel since it sets a limit of how many files you can monitor.

Sadly, closing as notgnome.
Comment 2 Inactive account 2016-10-24 11:44:09 UTC
Wait a second, but Nautilus shows the correct amount of items on the top level (only talking about the top level) after a restart so it is clearly checking what's there. Why can't it just do a refresh of the stats when the select a directory?

It clearly can check again as every time you click the "Properties" button it updates the item count (if there are more items than previously).
Comment 3 Carlos Soriano 2016-10-24 12:00:05 UTC
(In reply to cooks.go.hungry from comment #2)
> Wait a second, but Nautilus shows the correct amount of items on the top
> level (only talking about the top level) after a restart so it is clearly
> checking what's there. Why can't it just do a refresh of the stats when the
> select a directory?
> 
> It clearly can check again as every time you click the "Properties" button
> it updates the item count (if there are more items than previously).

We count them when showing them for the first time, as part of the loading process. We cannot detect when something changes, which is the problem here.

Refreshing takes time, it would have to show no count at all until that's processed, or show the wrong number and then update, which is probably fine. However, it's hard to know when to do it. One option is when selected, sure, but we could come with other situations and the disk will not stop spinning when using nautilus (or maybe is already the case?). Not sure we want that, we can take it into consideration indeed.
Comment 4 Carlos Soriano 2016-10-24 12:06:18 UTC
oh yeah, as Ernestas pointed out this is a duplicate

*** This bug has been marked as a duplicate of bug 768455 ***