On Tue, Aug 12, 2008 at 6:56 PM, Jim Meyering <[EMAIL PROTECTED]> wrote:
> "Andras Barna" <[EMAIL PROTECTED]> 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
_______________________________________________
Bug-coreutils mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/bug-coreutils
