Thank you for the answer. I thought noone will reply... ;) 06.06.2011 07:39, Ted Ts'o wrote: > On Sun, May 29, 2011 at 08:08:55PM +0400, Michael Tokarev wrote: >> Hello. >> >> Just noticed that at least on ext4, unlinking a >> non-existing file from a read-only filesystem >> results in EROFS instead of ENOENT. I'd expect >> it return ENOENT - it is more logical, at least >> in my opinion. >> >> For one, (readonly) NFS mount returns ENOENT in >> this case. > > Um, it doesn't for me. Testing on v3.0-rc1: > > # ls /test/foo; rm /test/foo > ls: cannot access /test/foo: No such file or directory > rm: cannot remove `/test/foo': No such file or directory This is a hack in coreutils rm to work around this kernel change. The comment at http://git.savannah.gnu.org/cgit/coreutils.git/tree/src/remove.c#n450 says: /* The unlinkat from kernels like linux-2.6.32 reports EROFS even for nonexistent files. When the file is indeed missing, map that to ENOENT, so that rm -f ignores it, as required. Even without -f, this is useful because it makes rm print the more precise diagnostic. */ so that rm(1) calls stat(2) to see if the file actually exist if unlinkat() returned EROFS, and turns this errno into ENOENT. That is, rm(1) output is not a good indicator. Use strace rm -f /test/foo 2>&1 | grep unlink to see the actual errno reported by the kernel. Here's the POSIX description of unlink (and unlinkat) again: http://pubs.opengroup.org/onlinepubs/009695399/functions/unlink.html Thanks! /mjt -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
