New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
NFS mounts do not update after an operation #582
Comments
@toonddd We check modification times of directories to trigger |
Is there a way to trigger a |
@toonddd Option |
From a (very) cursory glance at ranger's code and based on how it feels in usage, it appears they employ a similar strategy to how the custom command you provided works. I would love an option to enable a "trigger a |
@toonddd Is there a specific place you can link in ranger's code for the mentioned implementation? Shell commands are ubiquitous in I still think the solution for this issue might be related to mount options of the file system. I think it is fair for us to assume if the modification time of the directory is not changed then the directory is the same. Can you give more details about the filesystem and how you mount it on your system? Also can you make sure this is the case, that is modification time of the directory is not changed. For example you can show the output of the following scenario without
|
@gokcehan, for As for the way the filesystem is mounted, these are the parameters:
This is the output of the stat command on file create/remove (format: ╭toon@m1 ~/SNIP
╰─$ mkdir foo
╭toon@m1 ~/SNIP
╰─$ cd foo
╭toon@m1 ~/SNIP/foo
╰─$ stat .
File: .
Size: 0 Blocks: 0 IO Block: 1048576 directory
Device: 3dh/61d Inode: 166582 Links: 1
Access: (0755/drwxr-xr-x) Uid: ( 1000/ toon) Gid: ( 1000/ toon)
Access: 2021-02-28 17:17:57.922468962 +0100
Modify: 2021-02-28 17:17:57.922468962 +0100
Change: 2021-02-28 17:17:57.922468962 +0100
Birth: -
╭toon@m1 ~/SNIP/foo
╰─$ touch bar
╭toon@m1 ~/SNIP/foo
╰─$ stat .
File: .
Size: 6 Blocks: 0 IO Block: 1048576 directory
Device: 3dh/61d Inode: 166582 Links: 1
Access: (0755/drwxr-xr-x) Uid: ( 1000/ toon) Gid: ( 1000/ toon)
Access: 2021-02-28 17:17:57.922468962 +0100
Modify: 2021-02-28 17:18:02.732468944 +0100
Change: 2021-02-28 17:18:02.732468944 +0100
Birth: -
╭toon@m1 ~/SNIP/foo
╰─$ rm bar
╭toon@m1 ~/SNIP/foo
╰─$ stat .
File: .
Size: 0 Blocks: 0 IO Block: 1048576 directory
Device: 3dh/61d Inode: 166582 Links: 1
Access: (0755/drwxr-xr-x) Uid: ( 1000/ toon) Gid: ( 1000/ toon)
Access: 2021-02-28 17:17:57.922468962 +0100
Modify: 2021-02-28 17:18:06.772468930 +0100
Change: 2021-02-28 17:18:06.772468930 +0100
Birth: - Seems the modify time gets updated properly. |
@toonddd Thanks for digging through the code. It seems that ranger uses a similar strategy to use modification times to detect changes. It might be the case that loading is slower on
nfs man page mentions a "sync" options. I think it might make modifications appear as they occur. Maybe you can try this option for mounting. You can also try adding |
@gokcehan I tried the exact same scenario yesterday to coax out some async issues, but a When mounting with the Same behavior occurs with |
@toonddd Alright then I'm marking this as a bug even though I can't reproduce this with |
@gokcehan Using version r21, without a configuration file the issue persists. What log file do you want me to check? |
There are client and server log files in the temporary directory which is deleted on successful exit. You can either watch them from another terminal while the instance is started and still running (e.g.
If there is an issue loading directories, there might be an error in log files. |
When creating a folder or touching a file with a shell command issued from within lf, it spits out an error:
This also happens outside nfs mounts, I assume this is normal since the commands don't put anything on stdout. When removing the touched file or folder I only see the client and server emitting recv and listen logs. Upon refreshing (ctrl+r), it spits out:
|
Would it be possible to just reload when doing an operation? |
This issue occurs when inside NFS mounts (verified) and possibly other async-like filesystems (unverified)
Deleting, renaming, cutting, pasting, ... operations are not visible on folders/files most of the time.
Same when adding files by e.g. entering
$mkdir dir
or$touch file
.The changes do show up sporadically, but this behavior has no apparent consistency and seems to be some kind of race condition.
Adding
set period 1
to thelfrc
also doesn't make the change show up after 1 second has passed.Issuing a
reload
command does make the changes appear.The text was updated successfully, but these errors were encountered: