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

[Jim Meyering]

Szabolcs Szakacsits <address@hidden> 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.