hah 6.12 is more buggy:
sent them a mail

sartek at osol:/tmp/a$ mkdir -p f/f/f/f//f//f/f/f/f//f/f/f/f//f/
sartek at osol:/tmp/a$ /data/a/bin/rm --version|head -1
rm (GNU coreutils) 6.12
sartek at osol:/tmp/a$ /data/a/bin/rm -rf f
sartek at osol:/tmp/a$ echo $?
0
sartek at osol:/tmp/a$ ls f
f
sartek at osol:/tmp/a$ /data/a/bin/rm -r f
sartek at osol:/tmp/a$ echo $?
0
sartek at osol:/tmp/a$ ls f
f
sartek at osol:/tmp/a$


On Sun, Aug 10, 2008 at 6:40 PM, Szabolcs Szakacsits <szaka at ntfs-3g.org> 
wrote:
>
> On Sun, 10 Aug 2008, Andras Barna wrote:
>
>> solaris' rm works, gnu's not
>> $ /usr/gnu/bin/rm --version
>> rm (GNU coreutils) 6.7
>
> Great info, thanks. This is an 1.5+ year old coreutils but I couldn't
> reproduce the problem on Linux with the same (newer and older) coreutils
> versions.
>
> If the latest, version 6.12, coreutiles doesn't work either then please
> submit a bug report to them, noting that Solaris rm works and coreutils too
> on Linux.
>
> Thanks,
>           Szaka
>
>
>> On Sun, Aug 10, 2008 at 10:48 AM, Szabolcs Szakacsits <szaka at ntfs-3g.org> 
>> wrote:
>> >
>> > On Sun, 10 Aug 2008, Andras Barna wrote:
>> >> On Sun, Aug 10, 2008 at 12:53 AM, Szabolcs Szakacsits <szaka at 
>> >> ntfs-3g.org> wrote:
>> >> >
>> >> > On Fri, 8 Aug 2008, Andras Barna wrote:
>> >> >
>> >> >> am cc'ing desktopdiscuss, since we are talking now about autotools
>> >> >
>> >> > Thanks.
>> >> >
>> >> >> i applied the patch, seems ok and also i must add AM_PROG_LIBTOOL to
>> >> >> configure.ac coz: [0]
>> >> >
>> >> > Well, you shouldn't add it because it already should be there when 
>> >> > needed.
>> >> >
>> >> > The problem is with this recent patch:
>> >> >
>> >> >  
>> >> > http://mercurial.creo.hu/repos/ntfs-3g-hg/index.cgi/diff/a05ab13955c8/configure.ac
>> >> >
>> >> >> a minor error: ./configure: line 19337: LT_INIT: command not found
>> >> >>
>> >> >> i have no idea about the other problems. sorry
>> >> >>
>> >> >> [0]
>> >> >> libfuse-lite/Makefile.am:5: Libtool library used but `LIBTOOL' is 
>> >> >> undefined
>> >> >> libfuse-lite/Makefile.am:5:   The usual way to define `LIBTOOL' is to
>> >> >> add `AC_PROG_LIBTOOL'
>> >> >> libfuse-lite/Makefile.am:5:   to `configure.ac' and run `aclocal' and
>> >> >> `autoconf' again.
>> >> >> libfuse-lite/Makefile.am:5:   If `AC_PROG_LIBTOOL' is in
>> >> >> `configure.ac', make sure
>> >> >> libfuse-lite/Makefile.am:5:   its definition is in aclocal's search 
>> >> >> path.
>> >> >> libntfs-3g/Makefile.am:6: Libtool library used but `LIBTOOL' is 
>> >> >> undefined
>> >> >> libntfs-3g/Makefile.am:6:   The usual way to define `LIBTOOL' is to
>> >> >> add `AC_PROG_LIBTOOL'
>> >> >> libntfs-3g/Makefile.am:6:   to `configure.ac' and run `aclocal' and
>> >> >> `autoconf' again.
>> >> >> libntfs-3g/Makefile.am:6:   If `AC_PROG_LIBTOOL' is in `configure.ac', 
>> >> >> make sure
>> >> >> libntfs-3g/Makefile.am:6:   its definition is in aclocal's search path.
>> >> >
>> >> > Apparently your autoconf doesn't like the 'ifdef' construct in 
>> >> > configure.ac
>> >> > What's the version (autoconf --version)? Minimum 2.59 is needed 
>> >> > (enforced
>> >> > by configure.ac) and 2.61 is known to be ok (at least on Linux).
>> >> >
>> >>
>> >> it's 2.61
>> >
>> > Interesting.
>> >
>> >> > About the "rm: cannot remove directory `foo': Directory not empty" 
>> >> > problem.
>> >> >
>> >> > Is it always reproducible?
>> >>
>> >> uhm yes
>> >>
>> >> on opensolaris the PATH begins with /usr/gnu/bin, so we are talking
>> >> about the GNU rm see:
>> >> (sorry for this i always get lost in PATH's)
>> >>
>> >> sartek at osol:/tmp/a# mkdir -p
>> >> asdasd/asd/as/d/asd/asd/asd/asd/asdasd/as/das/das/da/sdas/das/das/da/sd/asd/asd/asd/as/das/d/asd/asd/asd/asd/as/das/d/asd/asd/asd/
>> >> sartek at osol:/tmp/a# which rm
>> >> /usr/gnu/bin/rm
>> >> sartek at osol:/tmp/a# rm -rf asdasd
>> >> rm: cannot remove directory `asdasd': Directory not empty
>> >> sartek at osol:/tmp/a# /usr/bin/rm -rf asdasd
>> >> sartek at osol:/tmp/a#
>> >
>> > I can't reproduce this either on Linux.
>> >
>> > Do you have the same problem using the Solaris 'rm' command as well?
>> >
>> > If not, then what's the output of 'rm --version'?
>> >
>> > Thanks,
>> >            Szaka
>> >
>> >
>> >> > I grepped the Solaris rm(1) code and it doesn't deal with 
>> >> > ENOTEMPTY/EEXIST
>> >> > (no need for it). So the problem was (is?) something else.
>> >> >
>> >> > The ntfs-3g driver can also 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).
>> >> >
>> >> > Three potential explanations:
>> >> >
>> >> > 1. rm "leaks" file descriptors during recursive removal. But it doesn't
>> >> > look like to be so by a quick look at the code. A tracing could confirm
>> >> > this pretty fast.
>> >> >
>> >> > 2. a child and removed file/directory was still in use (opened by at 
>> >> > least
>> >> > one process). Then the error message is the expected one.
>> >> >
>> >> > 3. a Solaris fuse issue.
>> >> >
>> >> > Regards,
>> >> >           Szaka
>> >> >
>> >> > --
>> >> > NTFS-3G:  http://ntfs-3g.org
>> >> >
>> >> >> On Fri, Aug 8, 2008 at 12:48 AM, Szabolcs Szakacsits <szaka at 
>> >> >> ntfs-3g.org> wrote:
>> >> >> >
>> >> >> > Hi,
>> >> >> >
>> >> >> > On Tue, 5 Aug 2008, Andras Barna wrote:
>> >> >> >
>> >> >> >> i'm on opensolaris 94
>> >> >> >> i just want to confirm that it works with gcc, but with 
>> >> >> >> sunstudioexpress.
>> >> >> >> i attach a log
>> >> >> >
>> >> >> > Thank you very much.
>> >> >> >
>> >> >> > It seems the only major problem is the lack of anonymous struct/union
>> >> >> > support in the Sun Studio compiler.
>> >> >> >
>> >> >> > Is it possible somehow to detect the Sun Studio compler in 
>> >> >> > configure.ac?
>> >> >> > Then users could be advised to install gcc.
>> >> >> >
>> >> >> > Another improvement could be this patch
>> >> >> >
>> >> >> > ------------------------------------------------>
>> >> >> > diff -u -r1.78 configure.ac
>> >> >> > --- configure.ac        17 Jul 2008 15:04:23 -0000      1.78
>> >> >> > +++ configure.ac        7 Aug 2008 20:53:57 -0000
>> >> >> > @@ -117,7 +117,7 @@
>> >> >> >  AC_GNU_SOURCE
>> >> >> >
>> >> >> >  # Programs
>> >> >> > -AC_PROG_CC
>> >> >> > +AC_PROG_CC(gcc cc)
>> >> >> >  AC_PROG_LN_S
>> >> >> >  AM_PROG_CC_C_O
>> >> >> >
>> >> >> > <------------------------------------------------
>> >> >> >
>> >> >> > which in theory would always prefer and use the gcc compiler over Sun
>> >> >> > Studio if both are installed. This way there would be no need to 
>> >> >> > manually
>> >> >> > set CC before compilation.
>> >> >> >
>> >> >> > Could somebody test the patch please?
>> >> >> >
>> >> >> >        unset CC
>> >> >> >        ./autogen.sh
>> >> >> >        ./configure
>> >> >> >        make
>> >> >> >
>> >> >> > The anonymous struct/union issue is keep being solved by developers 
>> >> >> > using
>> >> >> > old gcc and other compilers (it can be done in a few hours) but a 
>> >> >> > solution
>> >> >> > can be applied to upstream ntfs-3g only if it's completely 
>> >> >> > non-intrusive to
>> >> >> > all existing users.
>> >> >> >
>> >> >> > Two good solutions are
>> >> >> >
>> >> >> >  1. Detect compiler anonymous struct/union ability, set a macro 
>> >> >> > accordingly,
>> >> >> >    use it to conditionally (and smartly) define structs/unions and 
>> >> >> > convert
>> >> >> >    all relevant, direct struc/union member accesses to use get and 
>> >> >> > set
>> >> >> >    helper functions/macros.
>> >> >> >
>> >> >> >  2. Eliminate anonymous struct/union usage and demonstrate that the
>> >> >> >    generated machine codes are equivalent on the byte level. I very 
>> >> >> > much
>> >> >> >    doubt this would be true.
>> >> >> >
>> >> >> > Andras, I've seen your problem on HUP, namely something like this:
>> >> >> >
>> >> >> >  mkdir -p foo/bar/baz
>> >> >> >  rm -rf foo
>> >> >> >  rm: cannot remove directory `foo': Directory not empty
>> >> >> >
>> >> >> > Apparently Solaris's rm(8) checks only for EEXIST. ENOTEMPTY is also 
>> >> >> > valid
>> >> >> > in the above case according to POSIX. In the past ntfs-3g's rmdir(2)
>> >> >> > returned EEXIST but it was changed to ENOTEMPTY because most (Linux)
>> >> >> > programs expect ENOTEMPTY.
>> >> >> >
>> >> >> > If somebody could confirm the above then we would change the driver 
>> >> >> > to use
>> >> >> > EEXIST instead of ENOTEMPTY on Solaris.
>> >> >> >
>> >> >> > Thanks,
>> >> >> >           Szaka
>> >> >> >
>> >> >> > --
>> >> >> > NTFS-3G: http://ntfs-3g.org
>> >> >> >
>> >> >> >
>> >> >> >> On Tue, Aug 5, 2008 at 8:29 PM, Szabolcs Szakacsits <szaka at 
>> >> >> >> ntfs-3g.org> wrote:
>> >> >> >> >
>> >> >> >> > On Tue, 5 Aug 2008, Mark Phalan wrote:
>> >> >> >> >> On Tue, 2008-08-05 at 15:02 +0200, Mark Phalan wrote:
>> >> >> >> >> > On Mon, 2008-07-21 at 12:33 +0300, Szabolcs Szakacsits wrote:
>> >> >> >> >> > > On Thu, 17 Jul 2008, Szabolcs Szakacsits wrote:
>> >> >> >> >> > > >
>> >> >> >> >> > > > Could somebody please quickly try whether the below 
>> >> >> >> >> > > > package, integrating
>> >> >> >> >> > > > all the ideas we discussed here, compiles now on Solaris 
>> >> >> >> >> > > > without any
>> >> >> >> >> > > > patching and if not then what's the problem?
>> >> >> >> >> > > >
>> >> >> >> >> > > >         http://ntfs-3g.org/ntfs-3g-1.2717.tgz
>> >> >> >> >> > > >
>> >> >> >> >> > > > The usual './configure && make && make install' should 
>> >> >> >> >> > > > work but
>> >> >> >> >> > > > 'CFLAGS=-D__SOLARIS__  ./configure && ...' may be needed 
>> >> >> >> >> > > > for FUSE.
>> >> >> >> >> > >
>> >> >> >> >> > > Any success or failure?
>> >> >> >> >> >
>> >> >> >> >> > I just compiled ntfs-3g-1.2717 on the latest version of 
>> >> >> >> >> > Nevada/Solaris.
>> >> >> >> >> > It compiled without any problems!
>> >> >> >> >> >
>> >> >> >> >> > I haven't tested it yet though.
>> >> >> >> >>
>> >> >> >> >> Just tested it now with a Windows XP install. Reading and 
>> >> >> >> >> writing seem
>> >> >> >> >> to work!
>> >> >> >> >
>> >> >> >> > Thanks for testing.
>> >> >> >> >
>> >> >> >> >> Thanks for making the necessary changes to ntfs-3g :)
>> >> >> >> >>
>> >> >> >> >> One thing to note is that ntfs-3g doesn't compile well with the 
>> >> >> >> >> Sun
>> >> >> >> >> Studio compiler gcc must be used. In the future I'd like to be 
>> >> >> >> >> able to
>> >> >> >> >> compile it with Sun Studio too. I'll take a look and see what 
>> >> >> >> >> needs to
>> >> >> >> >> be changed.
>> >> >> >> >
>> >> >> >> > I think the below patch is needed. Maybe something else too?
>> >> >> >> >
>> >> >> >> > ---------------------------------------------------------------------->
>> >> >> >> > --- configure.ac        17 Jul 2008 15:04:23 -0000      1.78
>> >> >> >> > +++ configure.ac        5 Aug 2008 17:22:12 -0000
>> >> >> >> > @@ -277,8 +277,10 @@
>> >> >> >> >  ])
>> >> >> >> >  AC_SYS_LARGEFILE
>> >> >> >> >
>> >> >> >> > -# We add -Wall to enable some compiler warnings.
>> >> >> >> > -CFLAGS="${CFLAGS} -Wall"
>> >> >> >> > +if test "$GCC" = "yes" ; then
>> >> >> >> > +       # We add -Wall to enable some compiler warnings.
>> >> >> >> > +       CFLAGS="${CFLAGS} -Wall"
>> >> >> >> > +fi
>> >> >> >> >
>> >> >> >> >  if test "${enable_pedantic}" = "yes"; then
>> >> >> >> >        enable_warnings="yes"
>> >> >> >> > <---------------------------------------------------------------------
>> >> >> >> >
>> >> >> >> > Thanks again,
>> >> >> >> >                Szaka
>> >> >> >> >
>> >> >> >> > --
>> >> >> >> > NTFS-3G:  http://ntfs-3g.org
>> >> >> >> >
>> >> >> >> > _______________________________________________
>> >> >> >> > fuse-discuss mailing list
>> >> >> >> > fuse-discuss at opensolaris.org
>> >> >> >> > http://mail.opensolaris.org/mailman/listinfo/fuse-discuss
>> >> >> >>
>> >> >> >> --
>> >> >> >> Andy
>> >> >> >> http://blog.sartek.net
>> >> >>
>> >> >> --
>> >> >> Andy
>> >> >> http://blog.sartek.net
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> Andy
>> >> http://blog.sartek.net
>> >>
>> >
>> > --
>> > NTFS-3G:  http://ntfs-3g.org
>> >
>> >
>>
>>
>>
>> --
>> Andy
>> http://blog.sartek.net
>>
>
> --
> NTFS-3G:  http://ntfs-3g.org
>
>



-- 
Andy
http://blog.sartek.net

Reply via email to