'set watch' does not correctly refresh if pasting into a 'base' directory that's symlinked

[andrewferrier]

I'm seeing issues where pasted files do not reliably appear in lf on paste with the 'set watch' option.

This issue is easiest to explain with recreation steps.

From a terminal:

mkdir ~/a
ln -s ~/a ~/b  # now 'a' and 'b' are the 'same' directory
touch ~/a/xyz

• Open lf, with 'set watch' enabled: lf ~/a. This should highlight 'xyz'.
• Hit 'd' to copy into delete buffer, left to navigate to homedir, 'p' to paste.
• Scroll to 'xyz', hit 'd' again, scroll to navigate to 'b' (the 'original' directory), hit to navigate in, hit 'p' to paste.
• The file does not appear. It is however successfully copied, as demonstrated by navigating left and right again, or quitting/restarting lf etc.

(in my experience, whether it is the symlinked directory or the original one which causes this problem is unpredictable, I'm sure it's not "random" but I'm not sure what the pattern is - so sometimes it's pasting into 'a' which triggers it instead).

If 'set watch' is not enabled, this issue does not occur and the file appears 'instantly'.

lf version 41. Installed using Arch Linux package. btrfs is the underlying filesystem.

Thanks for all your hard work on lf, much appreciated!

[CatsDeservePets]

I could not reproduce this issue on r41 or the HEAD version.
However, lf recently fixed a bug regarding symlinks:

• fix: prevent following symlinks for cd #2423

Does compiling and using the HEAD version fix the bug for you?

[joelim-work]

I had a look, what happens is that fsnotify doesn't watch paths like ~/a or ~/b, it watches directories. So when watching a directory ~/a and a symlink ~/b that points to that directory, there is really only one directory that is registered and consequently all updates reported from fsnotify will be relative to that directory (i.e. ~/a/xyz was created).

I suspect the only way to solve this (barring changes to fsnotify itself) is to manually track symlinks so that they can be updated if the target directory does.

[andrewferrier]

For what it's worth, I did compile the HEAD version, and it doesn't seem to have the original problem, although I would appreciate others' views/tests on that, because now I cannot recreate the original problem with the original version of lf either. As I mentioned before, it does seem to occur somewhat 'randomly'; perhaps this is something to do with the order fsnotify notifications are registered or similar? If you're willing to hold this open for a little bit, I'll try and come back later and see if I can provide a deterministic set of recreation steps.