Re: rm && opensolaris && ntfs-3g problem

[Szabolcs Szakacsits]

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.

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. 

> >> 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?
 
Regards,  Szaka

--
NTFS-3G: http://ntfs-3g.org