Hi Solaris FUSE Developers, We're back with the GNU rm -rf failing with ntfs-3g on Solaris only. GNU rm on Linux is ok with ntfs-3g. Solaris rm is also ok with ntfs-3g but it works differently.
To reproduce the problem: 1. compile the latest coreutils, version 6.12 http://ftp.gnu.org/gnu/coreutils/coreutils-6.12.tar.gz 2. mkdir -p l/l/l/l/l/l 3. path/to/coreutils-6.12/src/rm -rf l Andras reports step 3 succeeds but 'l' is not removed. Truss traces are available in the bottom of the page at http://article.gmane.org/gmane.comp.gnu.coreutils.bugs/14256 According to Jim, coreutils maintainer, the problem is that the below syscall shouldn't succeed if 'l' still contains non-removed files: unlinkat(AT_FDCWD, "l", 0x00000000) = 0 Apparently this seems to be a Solaris FUSE problem unless GNU rm doesn't use the right arguments but something else it believes. There are some more info below. One can monitor what commands ntfs-3g is receving and returning by using the -o debug mount option, e.g. if ntfs-3g receives the UNLINK command at all, and if so, then what it returns. Regards, Szaka -- NTFS-3G: http://ntfs-3g.org On Thu, 14 Aug 2008, Jim Meyering wrote: > Szabolcs Szakacsits <[EMAIL PROTECTED]> wrote: > > Jim Meyering <jim <at> meyering.net> writes: > >> "Andras Barna" <andras.barna <at> gmail.com> wrote: > >> > On Tue, Aug 12, 2008 at 6:56 PM, Jim Meyering <jim <at> meyering.net> > >> > wrote: > >> ... > >> >> That suggests that the opensolaris ntfs support for unlinkat > >> >> doesn't work as documented. That unlinkat call is succeeding, > >> >> yet I presume there is a non-empty directory named "l" that it > >> >> fails to remove. > >> >> > >> >> There are two differences in how unlinkat is used between > >> >> coreutils and /usr/bin/rm: > >> >> - coreutils uses "0" as the third argument, and /bin/rm uses 0x1 > >> >> (which is probably AT_REMOVEDIR) > >> >> - coreutils uses AT_FDCWD as the first argument, and /bin/rm > >> >> uses a file descriptor. > >> >> > >> >> Since Solaris is where openat-style functions originated, I'm > >> >> surprised that their ntfs implementation would not adhere to the > >> >> documented specification. > >> > > >> > what you mean under "their ntfs implementation"? > >> > i thought we talk about ntfs-3g > >> > hint: http://ntfs-3g.org/ > >> > >> Sorry for the imprecision. > >> Obviously, I meant "the ntfs-3g" driver code, since > >> this seems to be ntfs-3g specific. It'd be good to know > >> if it is also specific to Solaris, and what precise version(s) > >> of ntfs-3g are affected, if only to document the problem > >> for people who encounter this in the future. > >> > >> For the record, can you tell us what versions you know to be affected? > > > > I asked Andras to report the bug here because ntfs-3g works with all > > gnu rm on Linux, and Solaris rm on Solaris. > > > > The only problem is gnu rm on Solaris. Version 6.7 gave ENOTEMPTY > > and the latest 6.12 reports no error when the directory is not > > removed. > > With 6.12, the error is here: > (from Andras' truss output) > > unlinkat(AT_FDCWD, "l", 0x00000000) = 0 > > i.e., unlinkat succeeds (returns 0), yet fails to remove the directory. > That is not a bug in coreutils. > > FWIW, that is the very first and only unlinkat call. > Once it succeeds in unlinking the command line argument, > GNU rm (6.12) must presume that its job is done. > > > The ntfs-3g driver can return ENOTEMPTY if a removed file/directory > > has an open file descriptor and its parent directory tried to be > > removed (this is a FUSE high-level API issue). > > > > A potential explanation could be for the ENOEMPTY problem if gnu rm > > "leaks" file descriptors during recursive removal. > > GNU rm does not leak anything, afaik. > > >> >> I do not plan to make GNU rm work around this bug. > >> > > >> > sorry for reporting it > >> > >> What I should have said is that working around this > >> system-and-file-system-specific bug in coreutils/gnulib would not be easy, > >> and would probably have a negative impact all other systems. However, > >> if someone can come up with a patch that is low-impact and safe looking, > >> I'll be happy to look at it. > > > > Personally I don't see where the problem is. Does gnu rm misinterpret > > something Solaris specific, or is it a problem with the Solaris FUSE > > kernel module? > > unlinkat is the problem. _______________________________________________ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils