Redraw window after delete

[snprajwal]

Many times, after deletion, files/folders are still visible. The window should be refreshed and redrawn after the delete action is completed

[gokcehan]

@snprajwal We do actually load directories after delete in here which should also trigger a redraw but I think this happened to me as well. It would help if there is a way to consistently produce this. If this is happening due to modification times not updating, there may not be much we can do about it.

[karabaja4]

Came here to report this bug and found this issue.

Yeah, it's very hard to reproduce it consistently, but it happens way too often not to notice.

Also, setting set period 1 doesn't seem to have any effect on directory refresh either.

[T0ille]

I also noticed that the window never redraws for me when deleting file with :delete and found this issue.

I am on r27 on WIndows. Anyone got a workaround for this?

[karabaja4]

@gokcehan

I managed to reproduce this consistently while I was working on some AUR packages (by accident).

This is my config: https://github.com/karabaja4/arch/blob/master/lf/lfrc

1. Download the archive: https://avacyn.aerium.hr/stuff/firefox-socket-control-git.tar.gz
2. Extract (:ex in my config) the archive by using the custom command.
3. Move into firefox-socket-control folder.
4. You will see a list of the following files:

firefox-socket-control
pkg
src
firefox-socket-control-git-1.5.326f892-1-any.pkg.tar.zst
firefox-socket-control-git.install
PKGBUILD
socketcontrol-1.5-fx.xpi

5. Select the following files/folders (s in my config):

firefox-socket-control
pkg
src
firefox-socket-control-git-1.5.326f892-1-any.pkg.tar.zst
socketcontrol-1.5-fx.xpi

6. Delete the files (d in my config)
7. The files that should now be listed are:

firefox-socket-control-git.install
PKGBUILD

but instead, the following are (incorrectly) listed:

pkg
src
firefox-socket-control-git-1.5.326f892-1-any.pkg.tar.zst
firefox-socket-control-git.install
PKGBUILD
socketcontrol-1.5-fx.xpi

YouTube video with the above procedure shown: https://www.youtube.com/watch?v=_8jA08Ln7zk

I can reproduce it 100% of the time.

[herrbischoff]

Same issue here. On macOS 13.4 (22F66), while browsing an SMB share, lf 30 doesn't refresh the file after deleting or moving a file or folder. I have to do a manual :reload every time, which is obviously infeasible. No other file manager, including ranger, nnn, mc and even Finder exhibits this issue for me.

If there's any data I can provide you with to home in on the issue, make sure to let me know.

[joelim-work]

Good news, I managed to reproduce the scenario given in https://github.com/gokcehan/lf/issues/792#issuecomment-1225065508. The issue happens on version r30 even without any custom user configuration. So the steps can be simplified to:

1. Download the archive: https://avacyn.aerium.hr/stuff/firefox-socket-control-git.tar.gz
2. Extract the archive using tar xvf
3. Start lf and move into the firefox-socket-control folder
4. Select and delete the files as specified above

---

After some debugging I found that when the files are deleted, the directory is loaded in two different places, which causes the following sequence of events:

1. The selected files are deleted by calling nav.del.
2. nav.del creates a separate thread to handle the actual file deletion.
3. After calling nav.del, the main thread proceeds to trigger a load event.
4. During the load event, the mtime of the directory is checked to see if it needs reloading (in this case it does).
5. The directory is reloaded, but at this time, the thread in step 2 has only deleted some of the requested files. Any remaining files will be displayed at the end, causing the result to be inconsistent.
6. After the directory is reloaded, the loadTime (last check time) of the directory is set to the current time, which will be slightly greater than the actual mtime of the directory.
7. After the thread in step 2 finishes running, it triggers another load event.
8. Similar to step 4, the mtime is checked again, but because the loadTime is now greater than the mtime due to step 6, the directory is considered to not have updated and nothing happens.
9. The final result displayed to the user is the set of files from step 5, which represents the state of a partially completed deletion.

The above sequence of events is very complex because it involves multiple threads, hopefully the code snippets below will help to explain:

Starting point for the delete command: https://github.com/gokcehan/lf/blob/027538eabf8a0f54e46946bdab19b90326709ce2/eval.go#L1168-L1185

Implementation of the nav.del function: https://github.com/gokcehan/lf/blob/027538eabf8a0f54e46946bdab19b90326709ce2/nav.go#L1451-L1488

Part of the nav.checkDir function which handles updating the directory: https://github.com/gokcehan/lf/blob/027538eabf8a0f54e46946bdab19b90326709ce2/nav.go#L483-L511

---

Anyway I think this issue can be solved simply by deleting the first load event, so that the only time the directory is reloaded is after the files are actually all deleted.

[karabaja4]

Same issue here. On macOS 13.4 (22F66), while browsing an SMB share, lf 30 doesn't refresh the file after deleting or moving a file or folder. I have to do a manual :reload every time, which is obviously infeasible. No other file manager, including ranger, nnn, mc and even Finder exhibits this issue for me.

If there's any data I can provide you with to home in on the issue, make sure to let me know.

Please note that this sounds like a completely different issue.

The issue that's being discussed here is that sometimes, very intermittently, lf doesn't update the files after a delete in a local folder, in scenarios described and solved by joelim-work above (thank you joelim!).

Files not being updated after the delete in a remote SMB folder (which sounds like an issue that can be observed 100% of the time) sounds like a different issue altogether, so it may be worth opening a new issue with a detailed description.

[herrbischoff]

Please note that this sounds like a completely different issue.

Maybe. As soon as a new release with the above changes is available, we'll see. From the issue description this race condition may actually be triggered 100% of the time on slower file systems like an SMB share.