Nemo doesn't refresh folder content 2.2.5

[CROSP]

After installing new cinnamon, I have noticed that nemo has a lot of issues. One major issue that it doesn't refreshes folder after it's content has been changed. For instance, creating new archive, after archive has been created it doesn't appear in folder, I need to refresh folder back - and than again go to this folder. Sometimes it doesn't help, so I need to wait some amount of time.
On another PC I have 2.2.4 version and it works perfectly. Please fix it

[bjd-pfq]

I have been noticing the same for the last couple of days. Send some file to Desktop, it doesn't show up.
Manually, in a terminal, move a file from a directory that's also open in nemo to another place, and it isn't remove in the nemo view.

[diontje]

+1 seeing this in 3.2.2

[ChrisJan00]

+1 seeing this in 3.2.2

[ChrisJan00]

I might have solved it in my computer by increasing the limit of inode watches.

I was using Valgrind to profile an application I am working on (completely unrelated to this), and it was complaining about having reached the limit of watches. Searching online for a solution to that problem brought me to this link: https://unix.stackexchange.com/questions/13751/kernel-inotify-watch-limit-reached . Following the instructions fixed the problem with Valgrind. Apparently, as a side effect, it also fixed this issue with Nemo.

I have the same problem. The manifestation of it on my system, thus far - and it's a newly installed, and fully updated, version of Mint Cinnamon 18.3 - is as follows. In windowed Nemo, I create a link to a file. I draw the link to the desktop. The link remains visible in the window / folder it was created it - until I tell Nemo to refresh that window.

Compare also this bug report, which itself cites a further report: #1509

Another way to reproduce the problem: drag files from an archive, opened in Archive Manager, to a Nemo window. The files do not appear until one refreshes the latter.

I think I have found the cause of this problem. The problem is caused, I think, by too low a setting - too low for one's system, anyway - of fs.inotify.max_user_watches.

The value can be set in sysctl.conf, thusly:

fs.inotify.max_user_watches=524288

Each 'watch' takes 1KB of unswappable memory. So, 524288 sets max usage to 500MB. Default = 8MB, I think.

[mtwebster]

A few of us that use Slack desktop run into this fairly often - I'm not sure if it's just Slack or 'electron' apps.

A few of us that use Slack desktop run into this fairly often - I'm not sure if it's just Slack or 'electron' apps.

Well, I found a command on the web that lists processes that use the 'watch' facility, and on my machine those include: pusleaudio; conky; cinnamon-screen; csd-color; sublime_text; polkitd; NetworkManager; nemo; ulauncher; and many more. Still, I do not know how heavily each of these is using the watcher doobery.

Now:

1. this setting being set too low can cause many problems - for it can affect Nemo, KeePass, Wireguard, mounting drives and quite possibly more;
2. the problems can be hard to diagnose, i.e. the culprit (viz., fs.inotify.max_user_watches being too low) is not always obvious;
3. increasing - even, say, trippling - the default value still doesn't allocate much RAM.

I infer that there's a strong case for Mint increasing this value by default.
[Edited]

[N-z0]

The issue still unresolved at this date,
Can reload the view with ctrl+R
But what if you forget to do it, and delete a folder because apparently empty...

[Jeremy7701]

Since it's only actual inotify watches used that influence memory usage, I always use fs.inotify.max_user_watches=524288.

This was because a media server program - minidlna issued warnings that the default fs.inotify.max_user_watches value was too low.

[github-actions]

This issue has been automatically marked as stale because it has not had
any activity in over 2 years.

If this issue is still relevant:

• Please test on a current version of this package.
• Add a comment with your findings

If no activity occurs in the next 30 days, this issue will be
automatically closed. Issues can be reopened if needed.

[github-actions]

This issue has been automatically closed due to inactivity.

If you can still reproduce this issue on a current version,
please feel free to reopen it with updated information.