Re: rm opensolaris ntfs-3g problem
On Wed, Aug 13, 2008 at 9:39 PM, Jim Meyering [EMAIL PROTECTED] wrote: Andras Barna [EMAIL PROTECTED] wrote: On Tue, Aug 12, 2008 at 6:56 PM, Jim Meyering [EMAIL PROTECTED] 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? it's the latest ntfs-3g ok, let's say that ntfs-3g is buggy, these are bugs - different versions of GNU rm behaves different? - returns 0 but it not succeed - again with rm 6.7 i can rm directories with -r but -rf 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. I'm hoping we can ignore it, i.e., because the bug is only in versions that few will use. really? again: coreutils is integrated to opensolaris see:http://opensolaris.org/os/community/arc/caselog/2007/048/ and GNU coreutils are used on other NON linux OS too, *bsd etc. i thought that gnu is not limited to linux -- Andy http://blog.sartek.net ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: rm opensolaris ntfs-3g problem
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. 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. 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? Regards, Szaka -- NTFS-3G: http://ntfs-3g.org ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: rm opensolaris ntfs-3g problem
Andras Barna [EMAIL PROTECTED] wrote: On Wed, Aug 13, 2008 at 9:39 PM, Jim Meyering [EMAIL PROTECTED] wrote: Andras Barna [EMAIL PROTECTED] wrote: On Tue, Aug 12, 2008 at 6:56 PM, Jim Meyering [EMAIL PROTECTED] 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? it's the latest ntfs-3g ok, let's say that ntfs-3g is buggy, these are bugs - different versions of GNU rm behaves different? Those two versions of rm use different approaches, that the newer 6.12 would trigger a bug while the older one does not is not surprising. - returns 0 but it not succeed The unlinkat syscall it at fault. Your truss output shows that unlinkat returns 0 even though it appears not to remove the named directory. GNU rm merely propagates that success to its exit status. - again with rm 6.7 i can rm directories with -r but -rf Since afaik, this happens only with ntfs-3g, and there is such an egregious syscall failure exposed by coreutils-6.12, I haven't investigated. 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. I'm hoping we can ignore it, i.e., because the bug is only in versions that few will use. really? again: coreutils is integrated to opensolaris see:http://opensolaris.org/os/community/arc/caselog/2007/048/ and GNU coreutils are used on other NON linux OS too, *bsd etc. i thought that gnu is not limited to linux It is not, of course. And if you can show that coreutils is at fault, it'll surely be fixed promptly. So far, the evidence suggests that this is not a bug in coreutils ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: rm opensolaris ntfs-3g problem
Szabolcs Szakacsits [EMAIL PROTECTED] 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, 0x) = 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. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: rm opensolaris ntfs-3g problem
Hi Solaris FUSE Developers, We're back with the GNU rm -rf failing with ntfs-3g on Solaris only. GNU rm on Linux is ok with ntfs-3g. Solaris rm is also ok with ntfs-3g but it works differently. To reproduce the problem: 1. compile the latest coreutils, version 6.12 http://ftp.gnu.org/gnu/coreutils/coreutils-6.12.tar.gz 2. mkdir -p l/l/l/l/l/l 3. path/to/coreutils-6.12/src/rm -rf l Andras reports step 3 succeeds but 'l' is not removed. Truss traces are available in the bottom of the page at http://article.gmane.org/gmane.comp.gnu.coreutils.bugs/14256 According to Jim, coreutils maintainer, the problem is that the below syscall shouldn't succeed if 'l' still contains non-removed files: unlinkat(AT_FDCWD, l, 0x) = 0 Apparently this seems to be a Solaris FUSE problem unless GNU rm doesn't use the right arguments but something else it believes. There are some more info below. One can monitor what commands ntfs-3g is receving and returning by using the -o debug mount option, e.g. if ntfs-3g receives the UNLINK command at all, and if so, then what it returns. Regards, Szaka -- NTFS-3G: http://ntfs-3g.org On Thu, 14 Aug 2008, Jim Meyering wrote: Szabolcs Szakacsits [EMAIL PROTECTED] 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, 0x) = 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. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: rm opensolaris ntfs-3g problem
On Thu, 14 Aug 2008, Andras Barna wrote: when I execute rm (6.12) -r directory: unique: 202, opcode: ACCESS (34), nodeid: 1, insize: 48 ACCESS / 011 unique: 202, error: -89 (Operation not applicable), outsize: 16 unique: 203, opcode: LOOKUP (1), nodeid: 1, insize: 42 LOOKUP /o NODEID: 9 unique: 203, error: 0 (Error 0), outsize: 136 unique: 204, opcode: GETATTR (3), nodeid: 9, insize: 40 unique: 204, error: 0 (Error 0), outsize: 112 unique: 205, opcode: ACCESS (34), nodeid: 1, insize: 48 ACCESS / 011 unique: 205, error: -89 (Operation not applicable), outsize: 16 unique: 206, opcode: LOOKUP (1), nodeid: 1, insize: 42 LOOKUP /o NODEID: 9 unique: 206, error: 0 (Error 0), outsize: 136 unique: 207, opcode: ACCESS (34), nodeid: 9, insize: 48 ACCESS /o 012 unique: 207, error: -89 (Operation not applicable), outsize: 16 unique: 208, opcode: ACCESS (34), nodeid: 1, insize: 48 ACCESS / 011 unique: 208, error: -89 (Operation not applicable), outsize: 16 unique: 209, opcode: LOOKUP (1), nodeid: 1, insize: 42 LOOKUP /o NODEID: 9 unique: 209, error: 0 (Error 0), outsize: 136 unique: 210, opcode: UNLINK (10), nodeid: 1, insize: 42 UNLINK /o unique: 210, error: -93 (Directory not empty), outsize: 16 ntfs-3g correctly returns ENOTEMPTY but this information gets lost and arrives as success to gnu rm. This indeed looks to be a problem in Solaris. Thanks, Szaka unique: 211, opcode: ACCESS (34), nodeid: 1, insize: 48 ACCESS / 011 unique: 211, error: -89 (Operation not applicable), outsize: 16 unique: 212, opcode: GETATTR (3), nodeid: 1, insize: 40 unique: 212, error: 0 (Error 0), outsize: 112 On Thu, Aug 14, 2008 at 4:04 PM, Szabolcs Szakacsits [EMAIL PROTECTED] wrote: Hi Solaris FUSE Developers, We're back with the GNU rm -rf failing with ntfs-3g on Solaris only. GNU rm on Linux is ok with ntfs-3g. Solaris rm is also ok with ntfs-3g but it works differently. To reproduce the problem: 1. compile the latest coreutils, version 6.12 http://ftp.gnu.org/gnu/coreutils/coreutils-6.12.tar.gz 2. mkdir -p l/l/l/l/l/l 3. path/to/coreutils-6.12/src/rm -rf l Andras reports step 3 succeeds but 'l' is not removed. Truss traces are available in the bottom of the page at http://article.gmane.org/gmane.comp.gnu.coreutils.bugs/14256 According to Jim, coreutils maintainer, the problem is that the below syscall shouldn't succeed if 'l' still contains non-removed files: unlinkat(AT_FDCWD, l, 0x) = 0 Apparently this seems to be a Solaris FUSE problem unless GNU rm doesn't use the right arguments but something else it believes. There are some more info below. One can monitor what commands ntfs-3g is receving and returning by using the -o debug mount option, e.g. if ntfs-3g receives the UNLINK command at all, and if so, then what it returns. Regards, Szaka -- NTFS-3G: http://ntfs-3g.org On Thu, 14 Aug 2008, Jim Meyering wrote: Szabolcs Szakacsits [EMAIL PROTECTED] 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, 0x) = 0 i.e., unlinkat succeeds (returns 0), yet fails to remove the directory. That is not a bug in coreutils.
Re: rm opensolaris ntfs-3g problem
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/... ]
fstatat64(AT_FDCWD, l, 0x080478E0, 0x1000) = 0
getprivimplinfo(0x08046FA0, 2076) = 0
mmap(0x0001, 65536, PROT_READ|PROT_WRITE|PROT_EXEC,
MAP_PRIVATE|MAP_ANON|MAP_ALIGN, -1, 0) = 0xD078
sysconfig(_CONFIG_NGROUPS)= 16
zone_lookup(0x) = 0
zone_getattr(0, ZONE_ATTR_PRIVSET, 0xD0A20248, 12) = 12
getppriv(PRIV_EFFECTIVE, {0002e200}) = 0
brk(0x080980E0) = 0
brk(0x0809A0E0) = 0
access(l, W_OK|E_OK)= 0
getppriv(PRIV_EFFECTIVE, {0002e200}) = 0
unlinkat(AT_FDCWD, l, 0x) = 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.
I do not plan to make GNU rm work around this bug.
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: rm opensolaris ntfs-3g problem
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, 0x1000) = 0
getprivimplinfo(0x08046FA0, 2076) = 0
mmap(0x0001, 65536, PROT_READ|PROT_WRITE|PROT_EXEC,
MAP_PRIVATE|MAP_ANON|MAP_ALIGN, -1, 0) = 0xD078
sysconfig(_CONFIG_NGROUPS)= 16
zone_lookup(0x) = 0
zone_getattr(0, ZONE_ATTR_PRIVSET, 0xD0A20248, 12) = 12
getppriv(PRIV_EFFECTIVE, {0002e200}) = 0
brk(0x080980E0) = 0
brk(0x0809A0E0) = 0
access(l, W_OK|E_OK)= 0
getppriv(PRIV_EFFECTIVE, {0002e200}) = 0
unlinkat(AT_FDCWD, l, 0x) = 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
Re: rm opensolaris ntfs-3g problem
On Sun, 10 Aug 2008, Andras Barna wrote: on opensolaris (update 94) can't remove recursively directories. @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: /usr/gnu/bin/rm --version|head -1 rm (GNU coreutils) 6.7 @osol /ntfs: rm -rf t rm: cannot remove directory `t': Directory not empty @osol /ntfs: rm -r t @osol /ntfs: ls t ls: cannot access t: No such file or directory This example shows the default rm (PATH not shown) failing to remove a directory tree, but succeeding on the second attempt. @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 @osol /ntfs: /usr/bin/rm --version /usr/bin/rm: illegal option -- version usage: rm [-fiRr] file ... @osol /ntfs: /usr/bin/rm -r t @osol /ntfs: ls t ls: cannot access t: No such file or directory This example show GNU coreutils rm v6.12 failing to remove a directory tree; even though the exit status is 0, not all files are deleted. This is a bug. @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: /usr/bin/rm -rf t @osol /ntfs: ls t ls: cannot access t: No such file or directory This example shows /usr/bin/rm successfully deleting a directory tree. To determine whether this is a bug with GNU rm or interactions between your kernel and the NTFS filesystem, it's necessary to trace the system calls and their return values - hopefully your solaris system has truss installed, in which case you could try to repeat the failing commands given above like so: $ truss -o rm-trace.txt /path/to/rm -r t If you are able to interpret the output of truss, please try to identify where GNU rm and solaris rm differ in their system calls, specifically which files are removed with unlink(2). If not, then please just attach the truss output, ideally compressed. Cheers, Phil ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: rm opensolaris ntfs-3g problem
On Mon, Aug 11, 2008 at 11:39 AM, Philip Rowlands [EMAIL PROTECTED] wrote: On Sun, 10 Aug 2008, Andras Barna wrote: on opensolaris (update 94) can't remove recursively directories. @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: /usr/gnu/bin/rm --version|head -1 rm (GNU coreutils) 6.7 @osol /ntfs: rm -rf t rm: cannot remove directory `t': Directory not empty @osol /ntfs: rm -r t @osol /ntfs: ls t ls: cannot access t: No such file or directory This example shows the default rm (PATH not shown) failing to remove a directory tree, but succeeding on the second attempt. sorry for that that's /usr/gnu/bin/rm (/usr/gnu/bin is the first in PATH on opensolaris) @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 @osol /ntfs: /usr/bin/rm --version /usr/bin/rm: illegal option -- version usage: rm [-fiRr] file ... @osol /ntfs: /usr/bin/rm -r t @osol /ntfs: ls t ls: cannot access t: No such file or directory This example show GNU coreutils rm v6.12 failing to remove a directory tree; even though the exit status is 0, not all files are deleted. This is a bug. @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: /usr/bin/rm -rf t @osol /ntfs: ls t ls: cannot access t: No such file or directory This example shows /usr/bin/rm successfully deleting a directory tree. To determine whether this is a bug with GNU rm or interactions between your kernel and the NTFS filesystem, it's necessary to trace the system calls and their return values - hopefully your solaris system has truss installed, in which case you could try to repeat the failing commands given above like so: $ truss -o rm-trace.txt /path/to/rm -r t If you are able to interpret the output of truss, please try to identify where GNU rm and solaris rm differ in their system calls, specifically which files are removed with unlink(2). If not, then please just attach the truss output, ideally compressed. attached thanks Cheers, Phil -- Andy http://blog.sartek.net trussrm.tar.gz Description: GNU Zip compressed data ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
