[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: rm && opensolaris && ntfs-3g problem
From: |
Szabolcs Szakacsits |
Subject: |
Re: rm && opensolaris && ntfs-3g problem |
Date: |
Thu, 14 Aug 2008 16:04:45 +0300 (EEST) |
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", 0x00000000) = 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 <address@hidden> 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", 0x00000000) = 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.
- 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, Jim Meyering, 2008/08/13
- Re: rm && opensolaris && ntfs-3g problem, Andras Barna, 2008/08/13
- Re: rm && opensolaris && ntfs-3g problem, Jim Meyering, 2008/08/14
- Re: rm && opensolaris && ntfs-3g problem, Andras Barna, 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, Jim Meyering, 2008/08/14
- Re: rm && opensolaris && ntfs-3g problem,
Szabolcs Szakacsits <=
- 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