Ticket #2782 (new defect)

Opened 4 years ago

Last modified 5 weeks ago

MC and snapshots on FreeBSD

Reported by: maurizio4mc Owned by:
Priority: major Milestone: Future Releases
Component: mc-core Version: master
Keywords: zfs snapshot Cc: moiseev@…
Blocked By: Blocking:
Branch state: no branch Votes for changeset:

Description

Is not possible to browse .zfs directories with midnight commander if snapshots are hidden, if snapshots are visible MC works.

How to reproduce the problem:
1) cd /tank0/.zfs/snapshot/<snapdir>/
2) mc
MC shows the root directory.

[ssh@clover-nas /]$ uname -a
FreeBSD clover-nas 8.2-RELEASE FreeBSD 8.2-RELEASE #0: Thu Mar 10 17:42:35 UTC 2011 ssh@…:/usr/obj/usr/src/sys/GENERIC amd64

[ssh@clover-nas /]$ mc -V
GNU Midnight Commander 4.8.1.1
Built with GLib 2.28.8
Using the S-Lang library with terminfo database
With builtin Editor
With subshell support as default
With support for background operations
With mouse support on xterm
With internationalization support
With multiple codepages support
Virtual File Systems: cpiofs, tarfs, sfs, extfs, ftpfs, fish, smbfs
Data types: char: 8; int: 32; long: 64; void *: 64; size_t: 64; off_t: 64;

[ssh@clover-nas /]$ LC_MESSAGES=C mc -F
Home directory: /home/ssh

[System data]

Config directory: /usr/local/etc/mc/
Data directory: /usr/local/share/mc/
VFS plugins and scripts: /usr/local/libexec/mc/

extfs.d: /usr/local/libexec/mc/extfs.d/
fish: /usr/local/libexec/mc/fish/

[User data]

Config directory: /home/ssh/.config/mc/
Data directory: /home/ssh/.local/share/mc/

skins: /home/ssh/.local/share/mc/skins/
extfs.d: /home/ssh/.local/share/mc/extfs.d/
fish: /home/ssh/.local/share/mc/fish/

Cache directory: /home/ssh/.cache/mc/

[ssh@clover-nas /]$ mc --configure-options

'--enable-vfs-smb' '--with-configdir=/usr/local/etc' '--with-codepagedir=/usr/local/etc/codepages' '--without-x' '--with-screen=slang' '--with-slang-includes=/usr/local/include' '--prefix=/usr/local' '--mandir=/usr/local/man' '--infodir=/usr/local/info/' '--build=amd64-portbld-freebsd8.2' 'build_alias=amd64-portbld-freebsd8.2' 'CC=cc' 'CFLAGS=-O2 -pipe -fno-strict-aliasing' 'LDFLAGS= -L/usr/local/lib' 'CPPFLAGS=-I/usr/local/include' 'CPP=cpp'

Change History

comment:1 follow-up: ↓ 2 Changed 4 years ago by angel_il

can you try the current 'master', is the bug still reproducible?

Version 1, edited 4 years ago by andrew_b (previous) (next) (diff)

comment:2 in reply to: ↑ 1 Changed 4 years ago by maurizio4mc

Replying to angel_il:

can you try the current 'master', is the bug still reproducable?

I have the same bug with the version downloaded with git:
ssh@clover-nas /tmp/mc_test]$ bin/mc -V
GNU Midnight Commander 4.8.2-71-g5fe2f82
Built with GLib 2.28.8
Using the ncurses library
With builtin Editor
With subshell support as default
With support for background operations
With mouse support on xterm
With support for X11 events
With internationalization support
With multiple codepages support
Virtual File Systems: cpiofs, tarfs, sfs, extfs, ftpfs, fish
Data types: char: 8; int: 32; long: 64; void *: 64; size_t: 64; off_t: 64;

The same error happens with the latest PCBSD 9.0 and mc v. 4.8.2-71-g5fe2f82 or mc v. 4.7.5.5.
[maurizio@presario ~]$ uname -a
FreeBSD presario 9.0-RELEASE FreeBSD 9.0-RELEASE #3: Tue Dec 27 14:14:29 PST 2011 root@…:/usr/obj/builds/amd64/pcbsd-build90/fbsd-source/9.0/sys/GENERIC amd64

comment:3 Changed 3 years ago by samu

Bump. This bug still appears on FreeBSD 9.1-STABLE, with MC 4.8.8:

$ LC_MESSAGES=C mc -V
GNU Midnight Commander 4.8.8
Built with GLib 2.34.3
Using the S-Lang library with terminfo database
With builtin Editor
With subshell support as default
With support for background operations
With mouse support on xterm
With internationalization support
With multiple codepages support
Virtual File Systems: cpiofs, tarfs, sfs, extfs, ftpfs, sftpfs, fish, smbfs
Data types: char: 8; int: 32; long: 64; void *: 64; size_t: 64; off_t: 64;
$ LC_MESSAGES=C mc -F
Root directory: /home/samu

[System data]
    Config directory: /usr/local/etc/mc/
    Data directory:   /usr/local/share/mc/
    File extension handlers: /usr/local/libexec/mc/ext.d/
    VFS plugins and scripts: /usr/local/libexec/mc/
	extfs.d:        /usr/local/libexec/mc/extfs.d/
	fish:           /usr/local/libexec/mc/fish/

[User data]
    Config directory: /home/samu/.config/mc/
    Data directory:   /home/samu/.local/share/mc/
	skins:          /home/samu/.local/share/mc/skins/
	extfs.d:        /home/samu/.local/share/mc/extfs.d/
	fish:           /home/samu/.local/share/mc/fish/
	mcedit macros:  /home/samu/.local/share/mc/mc.macros
	mcedit external macros: /home/samu/.local/share/mc/mcedit/macros.d/macro.*
    Cache directory:  /home/samu/.cache/mc/
$ mc --configure-options
 '--enable-vfs-smb' '--with-configdir=/usr/local/etc' '--with-codepagedir=/usr/local/etc/codepages' '--without-x' '--with-screen=slang' '--with-slang-includes=/usr/local/include' '--prefix=/usr/local' '--mandir=/usr/local/man' '--infodir=/usr/local/info/' '--build=amd64-portbld-freebsd9.1' 'build_alias=amd64-portbld-freebsd9.1' 'CC=cc' 'CFLAGS=-O2 -fstack-protector-all -pipe -march=nocona -fno-strict-aliasing' 'LDFLAGS= -L/usr/local/lib' 'CPPFLAGS=-I/usr/local/include' 'CPP=cpp' 'PKG_CONFIG=pkgconf'

After mc is launched in a snapshot directory, you can see a red error, with the following message: "Cannot read directory contents".

comment:4 Changed 6 weeks ago by moiseev

  • Keywords zfs snapshot added
  • Cc moiseev@… added

Confirming that this still occurs with 10.3-RELEASE and MC 4.8.16.

Sorry, but I don't understand why issue with major priority stays unresolved over 3 years.

It's merely my speculation, but it might be MC uses system pwd command or same calls?

The .zfs subdirectories are not real directories, so pwd or /bin/pwd doesn't work for it, but pwd -L or /bin/pwd -L does:

# cd /tank/dir/.zfs/snapshot/2016-04-15_11.45.00--36h
# pwd
pwd: .: No such file or directory
# pwd -L
/tank/dir/.zfs/snapshot/2016-04-15_11.45.00--36h

comment:5 Changed 5 weeks ago by zaytsev

Sorry, but I don't understand why issue with major priority stays unresolved over 3 years.

Is it so hard to guess? Because there is no manpower to investigate it and come up with a fix.

Note: See TracTickets for help on using tickets.