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

[Andras Barna]

On Tue, Aug 12, 2008 at 6:56 PM, Jim Meyering <address@hidden> wrote:
> "Andras Barna" <address@hidden> wrote:
>>>> @osol /ntfs: /usr/gnu/bin/mkdir -p t/t/t/t/t/t/t/t/t/t//t/t///t//t/t/t/
>>>> @osol /ntfs: /data/a/bin/rm --version|head -1
>>>> rm (GNU coreutils) 6.12
>>>> @osol /ntfs: /data/a/bin/rm -rf t
>>>> @osol /ntfs: echo $?
>>>> 0
>>>> @osol /ntfs: ls t
>>>> t
>>>> @osol /ntfs: /data/a/bin/rm -r t
>>>> @osol /ntfs: ls t
>>>> t
>>>> @osol /ntfs: /data/a/bin/rm -r t
>>>> @osol /ntfs: echo $?
>>>> 0
>>>> @osol /ntfs: ls t
>>>> t
>
> Thanks for the truss output.
> For reference, this seems to be rm -r output (coreutils-6.12):
> [note that this appears to be using "l/l/l...", while the commands
> above used "t/t/t/..." ]
>

of course because i used a different directory tree there... what a miracle

>  fstatat64(AT_FDCWD, "l", 0x080478E0, 0x00001000) = 0
>  getprivimplinfo(0x08046FA0, 2076)             = 0
>  mmap(0x00010000, 65536, PROT_READ|PROT_WRITE|PROT_EXEC, 
> MAP_PRIVATE|MAP_ANON|MAP_ALIGN, -1, 0) = 0xD0780000
>  sysconfig(_CONFIG_NGROUPS)                    = 16
>  zone_lookup(0x00000000)                               = 0
>  zone_getattr(0, ZONE_ATTR_PRIVSET, 0xD0A20248, 12) = 12
>  getppriv(PRIV_EFFECTIVE, {00020000e200000000000000}) = 0
>  brk(0x080980E0)                                       = 0
>  brk(0x0809A0E0)                                       = 0
>  access("l", W_OK|E_OK)                                = 0
>  getppriv(PRIV_EFFECTIVE, {00020000e200000000000000}) = 0
>  unlinkat(AT_FDCWD, "l", 0x00000000)           = 0
>  llseek(0, 0, SEEK_CUR)                                = 326816
>  close(0)                                      = 0
>  close(1)                                      = 0
>  close(2)                                      = 0
>  _exit(0)
>
> 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/

> I do not plan to make GNU rm work around this bug.
>

sorry for reporting it


-- 
Andy
http://blog.sartek.net