example steps to reproduce:
1. `/etc/fstab` mount looks like this:
``
user@host:/mnt/remote/stuff /mnt/stuff fuse.sshfs
noauto,_netdev,user,transform_symlinks,identityfile=/path/to/key,default_permissions,uid=user,gid=user,allow_other,cache=no
0 0
``
2. `docker run -it --rm -v /mnt/stuff:/mnt:ro debian:11`
3. `apt update && apt install mc`
4. `mc /mnt`
directory will appear to be empty, even though `ls` on the same dir shows
real content.
changing debian image version in step 2 from 11 to 10 allows to browse
mountpoint's content as usual.
note that `mc` 2.8.22 is the default in `debian:10` (buster - aka:
oldstable) and `mc` 2.8.26 is the default in `debian:11` (bullseye - aka:
stable).
--
Ticket URL: <http://www.midnight-commander.org/ticket/4289>
Midnight Commander <https://midnight-commander.org>
Midnight Development Center
Comment (by basz):
``
+ LC_MESSAGES=C
+ mc -V
GNU Midnight Commander 4.8.26
Built with GLib 2.66.8
Built with S-Lang 2.3.2 with terminfo database
With builtin Editor and Aspell support
With subshell support as default
With support for background operations
With mouse support on xterm and Linux console
With support for X11 events
With internationalization support
With multiple codepages support
With ext2fs attributes support
Virtual File Systems:
cpiofs, tarfs, sfs, extfs, ext2undelfs, ftpfs, sftpfs, fish
Data types:
char: 8; int: 32; long: 64; void *: 64; size_t: 64; off_t: 64;
+ LC_MESSAGES=C
+ mc -F
Home directory: /home/user
Profile root directory: /home/user
[System data]
Config directory: /etc/mc/
Data directory: /usr/share/mc/
File extension handlers: /usr/lib/mc/ext.d/
VFS plugins and scripts: /usr/lib/mc/
extfs.d: /usr/lib/mc/extfs.d/
fish: /usr/lib/mc/fish/
[User data]
Config directory: /home/user/.config/mc/
Data directory: /home/user/.local/share/mc/
skins: /home/user/.local/share/mc/skins/
extfs.d: /home/user/.local/share/mc/extfs.d/
fish: /home/user/.local/share/mc/fish/
mcedit macros: /home/user/.local/share/mc/mc.macros
mcedit external macros:
/home/user/.local/share/mc/mcedit/macros.d/macro.*
Cache directory: /home/user/.cache/mc/
+ mc --configure-options
'--build=x86_64-linux-gnu' '--prefix=/usr' '--
includedir=${prefix}/include' '--mandir=${prefix}/share/man' '--
infodir=${prefix}/share/info' '--sysconfdir=/etc' '--localstatedir=/var'
'--disable-option-checking' '--libdir=${prefix}/lib/x86_64-linux-gnu' '--
runstatedir=/run' '--disable-maintainer-mode' '--disable-dependency-
tracking' 'AWK=awk' 'X11_WWW=x-www-browser' '--libexecdir=/usr/lib' '--
with-x' '--with-screen=slang' '--disable-rpath' '--disable-static'
'--disable-silent-rules' '--enable-aspell' '--enable-vfs-sftp' '--enable-
vfs-undelfs' '--enable-tests' 'build_alias=x86_64-linux-gnu' 'CFLAGS=-g
-O2 -ffile-prefix-map=/build/mc-xlv0ck/mc-4.8.26=. -fstack-protector-
strong -Wformat -Werror=format-security' 'LDFLAGS=-Wl,-z,relro -Wl,-z,now
-Wl,--as-needed' 'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2'
``
--
Ticket URL: <http://www.midnight-commander.org/ticket/4289#comment:1>
* component: mc-core => mc-vfs
* milestone: 4.8.28 => Future Releases
Old description:
> remote directory mounted with `sshfs` (FUSE) can be normally used from
> cmd-line, however it cannot be browsed with `mc` 2.8.26. the same mount
> point, on the same host, works fine with `mc` 2.8.22.
>
> example steps to reproduce:
>
> 1. `/etc/fstab` mount looks like this:
> ``
> user@host:/mnt/remote/stuff /mnt/stuff fuse.sshfs
> noauto,_netdev,user,transform_symlinks,identityfile=/path/to/key,default_permissions,uid=user,gid=user,allow_other,cache=no
> 0 0
> ``
>
> 2. `docker run -it --rm -v /mnt/stuff:/mnt:ro debian:11`
>
> 3. `apt update && apt install mc`
>
> 4. `mc /mnt`
>
> directory will appear to be empty, even though `ls` on the same dir
> shows real content.
>
> changing debian image version in step 2 from 11 to 10 allows to browse
> mountpoint's content as usual.
>
> note that `mc` 2.8.22 is the default in `debian:10` (buster - aka:
> oldstable) and `mc` 2.8.26 is the default in `debian:11` (bullseye - aka:
> stable).
New description:
remote directory mounted with `sshfs` (FUSE) can be normally used from
cmd-line, however it cannot be browsed with `mc` 2.8.26. the same mount
point, on the same host, works fine with `mc` 2.8.22.
example steps to reproduce:
1. `/etc/fstab` mount looks like this:
{{{
user@host:/mnt/remote/stuff /mnt/stuff fuse.sshfs
noauto,_netdev,user,transform_symlinks,identityfile=/path/to/key,default_permissions,uid=user,gid=user,allow_other,cache=no
0 0
}}}
2. `docker run -it --rm -v /mnt/stuff:/mnt:ro debian:11`
3. `apt update && apt install mc`
4. `mc /mnt`
directory will appear to be empty, even though `ls` on the same dir shows
real content.
changing debian image version in step 2 from 11 to 10 allows to browse
mountpoint's content as usual.
note that `mc` 2.8.22 is the default in `debian:10` (buster - aka:
oldstable) and `mc` 2.8.26 is the default in `debian:11` (bullseye - aka:
stable).
--
--
Ticket URL: <http://www.midnight-commander.org/ticket/4289#comment:2>
Comment (by andrew_b):
This is a result of #3987. Now mc calls the rewinddir(3) when reads a
directory. I think sshfs has a bug related to rewinddir(3). Disabling of
sshfs's cache should help.
Small test program can be find
[https://github.com/trapexit/mergerfs/issues/877 here].
--
Ticket URL: <http://www.midnight-commander.org/ticket/4289#comment:3>
Comment (by basz):
yes, this appears to be a problem with sshfs. i've checked the linked
program and indeed on "regular" directories, i get the same output for
both reads, yet for sshfs-mounts first read is good, but the second one
yields empty result. unfortunately disabling caching does not seem to
help.
anyway - we can close this ticket. i'll followup with sshfs team.
thank you. :)
--
Ticket URL: <http://www.midnight-commander.org/ticket/4289#comment:4>
Comment (by basz):
ticket on sshfs:
https://github.com/libfuse/sshfs/issues/278
--
Ticket URL: <http://www.midnight-commander.org/ticket/4289#comment:5>
* status: new => closed
* resolution: => invalid
* milestone: Future Releases =>
Comment:
Thanks!
--
Ticket URL: <http://www.midnight-commander.org/ticket/4289#comment:6>