[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: rm && opensolaris && ntfs-3g problem
From: |
Andras Barna |
Subject: |
Re: rm && opensolaris && ntfs-3g problem |
Date: |
Wed, 13 Aug 2008 21:22:25 +0300 |
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
- rm && opensolaris && ntfs-3g problem, Andras Barna, 2008/08/10
- Re: rm && opensolaris && ntfs-3g problem, Philip Rowlands, 2008/08/11
- Re: rm && opensolaris && ntfs-3g problem, Andras Barna, 2008/08/11
- Re: rm && opensolaris && ntfs-3g problem, Szabolcs Szakacsits, 2008/08/14
- Re: rm && opensolaris && ntfs-3g problem, Jim Meyering, 2008/08/14
- Re: rm && opensolaris && ntfs-3g problem, Szabolcs Szakacsits, 2008/08/14
- Re: rm && opensolaris && ntfs-3g problem, Andras Barna, 2008/08/14
- Re: rm && opensolaris && ntfs-3g problem, Szabolcs Szakacsits, 2008/08/14
- Re: [fuse-discuss] rm && opensolaris && ntfs-3g problem, Mark Phalan, 2008/08/18