An utterly bizarre bug; ls -l complains that the file doesn't exist
when it does, but goes on to list it anyway:
polya:~/teaching/WGGS-general/ASA2 Handbook/papers $ /bin/ls -l Module-C3/jun13-C3W.pdf
/bin/ls: Module-C3/jun13-C3W.pdf: No such file or directory
lrwxrwxrwx 1 jdg jdg 61 Oct 4 16:44 Module-C3/jun13-C3W.pdf -> /home/jdg/teaching/resources/AS-A2-papers/jun13/jun13-C3W.pdf
polya:~/teaching/WGGS-general/ASA2 Handbook/papers $ /bin/ls Module-C3/jun13-C3W.pdf
Module-C3/jun13-C3W.pdf
polya:~/teaching/WGGS-general/ASA2 Handbook/papers $ [ -f Module-C3/jun13-C3W.pdf ] && echo yes
yes
polya:~/teaching/WGGS-general/ASA2 Handbook/papers $ od -bc Module-C3/jun13-C3W.pdf | head -2
0000000 045 120 104 106 055 061 056 064 012 045 342 343 317 323 012 070
% P D F - 1 . 4 \n % 342 343 317 323 \n 8
I haven't got any idea what's going on here or why. The only thing I
can think might be involved is that /home/jdg is an encfs mount:
polya:~/teaching/WGGS-general/ASA2 Handbook/papers $ mount
[...]
encfs on /home/jdg type fuse.encfs (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other)
[...]
I'm happy to help debug this further if you can say what you'd like me
to do to test it. (I don't have time right now to go through the
coreutils source code myself to narrow down the source of the bug,
unfortunately.)
Julian
In general the most useful thing for debugging coreutils problems is to run it with strace, as the problems quite often end up being libc issues. (strace -o straceoutput.txt /bin/ls -l Module-C3/jun13-C3W.pdf) Mike Stone
Thanks! Attached is the strace output. So it seems that the problem
occurs at lines 124-125 of the strace output: the lstat succeeds, but
then lgetxattr("Module-C3/jun13-C3R.pdf", "security.selinux",
0xbee100, 255) fails, at which point the error message is written out
to stderr.
So I wonder whether it is because encfs doesn't interact very well
with linux attibutes?
Julian
coreutils to guess that ENOENT in this case really means ENOTSUP or EINVAL or something. I'd guess maybe encfs, which should be returning an appropriate error code? Or maybe fuse; I don't really know much about how those are implemented. Mike Stone
reassign 725429 fuse 2.9.2-4 retitle 725429 fuse: lgetxattr returns ENOENT instead of ENOSUP on encfs filesystem thanks [To fuse maintainer: please read the bug log; this may be a fuse bug or an encfs bug or a libattr bug - we are not sure, so please reassign if necessary. Thanks! Julian] Or it could be libattr perhaps? I'll reassign this bug to fuse, as the maintainer there might know whose responsibility this is. Julian
tag 725429 upstream tag 725429 help tag 725429 moreinfo thanks can you reproduce it with the version of fuse from experimental?
tag 725429 upstream tag 725429 help tag 725429 moreinfo thanks can you reproduce it with the version of fuse from experimental?
I just installed fuse and libfuse2 2.9.3-3 from experimental and see
exactly the same overt behaviour, and the strace output contains:
31696 lgetxattr("teaching/WGGS-general/ASA2 Handbook/papers/Module-C1/jan08-C1.doc", "security.selinux", 0x1876100, 255) = -1 ENOENT (No such file or directory)
Julian
I just installed fuse and libfuse2 2.9.3-3 from experimental and see
exactly the same overt behaviour, and the strace output contains:
31696 lgetxattr("teaching/WGGS-general/ASA2 Handbook/papers/Module-C1/jan08-C1.doc", "security.selinux", 0x1876100, 255) = -1 ENOENT (No such file or directory)
Julian
I just installed fuse and libfuse2 2.9.3-3 from experimental and see
exactly the same overt behaviour, and the strace output contains:
31696 lgetxattr("teaching/WGGS-general/ASA2 Handbook/papers/Module-C1/jan08-C1.doc", "security.selinux", 0x1876100, 255) = -1 ENOENT (No such file or directory)
Julian
reassign 725429 encfs retitle 725429 lgetxattr returns ENOENT instead of ENOSUP thanks i couldn't reproduce it with other fuse filesystems, so it seems to be an issue with encfs rather than fuse itself, thus reassigning.
Hi, I am not sure, but to me it seems that quite a few issues may be cause by the following bug in encfs reported upstream with patch, but still not implemented: https://code.google.com/p/encfs/issues/detail?id=151 [1] To read more about it (and debugging approach): https://code.google.com/p/encfs/issues/detail?id=162 [2] https://lists.gnu.org/archive/html/rdiff-backup-users/2010-05/msg00000.html [3] Please include it as a Debian patch until it is accepted upstream. Greetings, gw Links: ------ [1] https://code.google.com/p/encfs/issues/detail?id=151 [2] https://code.google.com/p/encfs/issues/detail?id=162 [3] https://lists.gnu.org/archive/html/rdiff-backup-users/2010-05/msg00000.html