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 Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils