Missing file update after move

[valoq]

There appears to be another strange bug regarding the watch feature that is triggered by moving files - But it is unreliable to reproduce.

When I found this I could reproduce the issue reliably like this:

Case A)

• files a, b, c and d are marked and moved to a a child directory (the original path is still visible in lfs left pane)
• The files are moved and displayed correctly in the new directory while their old location is correctly updated as empty

Case B)

• files a, b, c and d are in a directory, file a is deleted, files b, c and d are marked and moved to the subdirectory.
• The files are moved and displayed correctly in the new directory but they are still shown in the old path as well until a manual refresh is triggered.

After observing Case B) and repeating the bug several times, I rebooted and the bug could no longer be reproduced, leaving me with Case A) again

[joelim-work]

I tried case B and couldn't reproduce at all. Have you tried logging the fsnotify events to see what is going on? When moving files there should be Rename events (for the previous directory) and Create events (for the new directory).

[valoq]

Ok I found the trigger:

Case 1) If I create a new directory and move files there, the previous file location is not updated
Case 2 )If the files are instead moved to a preexisting directory, the bug is not triggered.

Case 1

2025/02/04 18:57:51 fsnotify event: CREATE        "/home/testuser/x"
2025/02/04 18:57:56 fsnotify event: RENAME        "./aa.png"
2025/02/04 18:57:56 fsnotify event: CREATE        "/home/testuser.homedir/x/aa.png" ← "./aa.png"
2025/02/04 18:57:56 fsnotify event: RENAME        "./bb.png"
2025/02/04 18:57:56 fsnotify event: CREATE        "./bb.png" ← "./bb.png"
2025/02/04 18:57:56 fsnotify event: CREATE        "./cc.png"
2025/02/04 18:57:56 fsnotify event: CREATE        "./dd.png"

Case 2

2025/02/04 18:58:20 fsnotify event: RENAME        "/home/testuser/aa.png"
2025/02/04 18:58:20 fsnotify event: CREATE        "/home/testuser/x/aa.png" ← "/home/testuser/aa.png"
2025/02/04 18:58:20 fsnotify event: RENAME        "/home/testuser/bb.png"
2025/02/04 18:58:20 fsnotify event: CREATE        "/home/testuser/x/bb.png" ← "/home/testuser/bb.png"
2025/02/04 18:58:20 fsnotify event: RENAME        "/home/testuser/cc.png"
2025/02/04 18:58:20 fsnotify event: CREATE        "/home/testuser/x/cc.png" ← "/home/testuser/cc.png"
2025/02/04 18:58:20 fsnotify event: RENAME        "/home/testuser/dd.png"
2025/02/04 18:58:20 fsnotify event: CREATE        "/home/testuser/x/dd.png" ← "/home/testuser/dd.png"

For some reason creating a new directory causes fsnotify to work with the relative path of the files instead of the absolute one.

In some cases the second mount path was also logged in the second case, so Im not sure this is related.

[joelim-work]

That's strange, I have never seen relative paths before. I was always under the impression that all paths provided by fsnotify would be absolute.

In any case I tried it again just now with the following commands but for me I only got absolute paths so I couldn't reproduce:

# test directory should contain a.txt, b.txt, c.txt and d.txt
# run after starting lf in test directory
mkdir foo
mv a.txt foo
mv b.txt c.txt d.txt foo

2025/02/05 14:33:22 event: CREATE        "/home/joelim/test/foo"
2025/02/05 14:33:24 event: RENAME        "/home/joelim/test/a.txt"
2025/02/05 14:33:24 event: CREATE        "/home/joelim/test/foo/a.txt" ← "/home/joelim/test/a.txt"
2025/02/05 14:33:27 event: RENAME        "/home/joelim/test/b.txt"
2025/02/05 14:33:27 event: CREATE        "/home/joelim/test/foo/b.txt" ← "/home/joelim/test/b.txt"
2025/02/05 14:33:27 event: RENAME        "/home/joelim/test/c.txt"
2025/02/05 14:33:27 event: CREATE        "/home/joelim/test/foo/c.txt" ← "/home/joelim/test/c.txt"
2025/02/05 14:33:27 event: RENAME        "/home/joelim/test/d.txt"
2025/02/05 14:33:27 event: CREATE        "/home/joelim/test/foo/d.txt" ← "/home/joelim/test/d.txt"

---

I searched the issue tracker in fsnotify and the only relevant thing I could find was fsnotify/fsnotify#160. It's possible that the path registered by lf was relative, which could cause the updates to also contain relative paths. Could you try logging the actual paths watched here:

lf/watch.go

Lines 67 to 76 in 4f0a5d6

	func (watch *watch) add(path string) {
	if watch.watcher == nil {
	return
	}
	// ignore /dev since write updates to /dev/tty causes high cpu usage
	if path != "/dev" {
	watch.watcher.Add(path)
	}
	}

lf tries to ensure that all paths are absolute for simplicity - if for some reason the path being registered is relative then you'll have to debug further, but if it's absolute then it indicates that it's an issue with fsnotify.

[valoq]

When logging all path that are added to the watcher, the logged path list are identical between the process that triggered the bug and the one where lf works as expected. In both cases the path are absolute and include both the previous path and the path of the newly recreated directory

I also confirmed/reproduced the bug on a partition without double mount to rule that out.

The only place where the relative path shows up is in the fsnotify event log

[valoq]

I did some more tests to find the change that introduced the bug:

When I use the current master branch and set fsnotify back to version 1.7.0 the bug still remains
When I use lf version r33 with either fsnotify version 1.7.0 or 1.8.0 the bug does not appear.

Therefore it seems to be an issue that was introduced with the recent changes.

[joelim-work]

There's not much I can do without a minimal example that actually reproduces the issue. If you have logged the calls for Watcher.Add in lf, can you mimic the behavior in a test program outside of lf and get the same result?

Also are you absolutely sure there are no relative paths being watched? You can use Watcher.WatchList to check.

[valoq]

There's not much I can do without a minimal example that actually reproduces the issue.

To reproduce the issue:

1. Start lf
2. create a new directory
3. cut a file
4. move to newly created directory
5. paste the file

The file will now be shown in both the previous and the new directory.

[joelim-work]

I meant an example that I can actually reproduce. I tried the above steps and it works fine for me:

1. lf -config /dev/null -command 'set watch true'
2. $mkdir foo
3. Use d to cut
4. Use l to enter the new directory
5. Use p to paste

With only two users in this discussion, there's not much sample size to help investigate the root cause, and the problem seems to have a 'works on my machine' nature. For the record I also tried this in a fresh Ubuntu VM today and couldn't reproduce there either.

[valoq]

It seems to have been a config issue after all.
When I use $mkdir foo lf behaves as expected, but I had used :mkdir foo instead, using the mkdir function I previously found in the wiki. I had added this function to my minimal lfrc for testing purposes too unfortunately ...

cmd mkdir %{{
    IFS=" "
    mkdir -p -- "$*"
    lf -remote "send $id select \"$*\""
}}

This seems to be what causes the bug for some reason, not lf itself, though some recent changed seems to have triggered this.

Update:
I have updated the wiki to use %mkdir in all examples instead.

[valoq]

Ok this seems to still be an issue after all but more complicated.
While moving a lot of files recently I noticed several intances where this bug appeared in one form or another.
Despite now using the default lfrc options for mkdir it also happened again when moving files to new directories but the bug also appeared after decompressing files and after moving files into trash.

In case it becomes relevant, this is my config for the mentioned functions:

cmd extract ${{
    set -f
    ouch decompress $f
}}

map a : extract; reload

cmd trash %trash-put -- $fx
map D trash

In multiple cases, the watch feature stopped working entirely after the bug appeared. Moved, copied and deleted files were no longer updated at all. This happened on a directory that was not mounted more then once, ruling out the fsnotify bug fsnotify/fsnotify#667 as the cause.

Unfortunately I did not yet manage to reproduce this issue reliably.

[jake-stewart]

@joelim-work @valoq reproducible example. hopefully the same bug.

lf-repro.mov

[joelim-work]

@jake-stewart Are you using a completely blank configuration with only set watch true? Like below:

lf -config /dev/null -command 'set watch true'

I tried doing the exact same thing and couldn't reproduce.

lf.mp4

I don't know if it's the same issue as OP, you can try logging the actual fsnotify events to see if it contains relative paths using the following patch:

diff --git a/watch.go b/watch.go
index d4f70d3..d4e38a0 100644
--- a/watch.go
+++ b/watch.go
@@ -81,6 +81,7 @@ func (watch *watch) loop() {
 	for {
 		select {
 		case ev := <-watch.events:
+			log.Printf("fsnotify event: %v", ev)
 			if ev.Has(fsnotify.Create) {
 				dir := filepath.Dir(ev.Name)
 				watch.addLoad(dir)

EDIT: I have no idea why the background in the video is green - apologies if it is hard to watch.

[jake-stewart]

Sorry, didn't know about that option and assumed it was a bug. It works great now. @joelim-work