GNU bug report logs - #10305
coreutils-8.14, "rm -r" fails with EBADF

Previous Next

Full log

Message #11 received at submit <at> debbugs.gnu.org (full text, mbox):

From: "Joachim Schmitz" <jojo <at> schmitz-digital.de>
To: "'Jim Meyering'" <jim <at> meyering.net>
Cc: bug-gnulib <at> gnu.org, bug-coreutils <at> gnu.org
Subject: RE: coreutils-8.14, "rm -r" fails with EBADF
Date: Thu, 15 Dec 2011 16:19:19 +0100

[Message part 1 (text/plain, inline)]

> From: Jim Meyering [mailto:jim <at> meyering.net]
> Sent: Thursday, December 15, 2011 3:17 PM
> To: Joachim Schmitz
> Cc: bug-coreutils <at> gnu.org; bug-gnulib <at> gnu.org
> Subject: Re: coreutils-8.14, "rm -r" fails with EBADF
> 
> Joachim Schmitz wrote:
> > I got coreutils-8.9, 8.13 and 8.14 to compile for my platform, and
> > most of the
> 
> Thanks for the report.
> More details will help us help you:
> 
> Which platform is that?

HP-NonStop

> Including your config.h might help.
Attached

> > utilities work, but as soon as it comes to recurring thru the file
> > system some utils fail, e.g.:
> >
> > ~/coreutils-8.14/src $ ./rm -R /tmp/foo
> >
> > ./rm: traversal failed: `/tmp/foo': Bad file descriptor
> >
> > ~/coreutils-8.14/src $ ./rm -r /tmp/foo
> >
> > ./rm: traversal failed: `/tmp/foo': Bad file descriptor
> >
> > ~/coreutils-8.14/src $
> >
> > ‘./ls –R /tmp/foo’ does work though:
> >
> > ~/coreutils-8.14/src $ ./ls -lr /tmp/foo
> >
> > total 0
> >
> > -rw-rw-r-- 1 jojo ITUGLIB 0 Dec 15 08:06 bar
> >
> > Does this ring a bell with one of you?
> 
> I haven't seen that before.
> It's obviously coming from this:
> 
>     case FTS_ERR:
>       /* Various failures, from opendir to ENOMEM, to failure to "return"
>          to preceding directory, can provoke this.  */
>       error (0, ent->fts_errno, _("traversal failed: %s"),
>              quote (ent->fts_path));
>       fts_skip_tree (fts, ent);
>       return RM_ERROR;
> 
> but what I really need to know is what happened just prior, in fts_read.
> Can you run gdb, set a breakpoint in fts_read and show us the result of stepping
> through fts_read?  That would be most useful.

Sorry, no gdb, the debugger here is calls eInspect (but is similar to gdb, as far as I know).
It goes thru fts_read() the 1st time without problem, on 2nd round fts_build(sp, BREAD) in ~/coreutils-8.14/lib/fts.c line 903 returns NULL, then the subsequent rm_fts (fts, ent, x) fails. It goues trhi fts_read() 2 more times after that.
 
> Or can you run strace -o log ./rm -r /tmp/foo and send us the "log" file?

Sorry, no strace here.
 
> > I don’t understand why one fails but the other works, and can’t seem
> > to fine the place where it goes wrong.
> 
> rm (and du, chmod, chown, etc.) use fts for tree traversal, while ls still uses
> hand-rolled (and thus unnecessarily limited) recursion.

Ah, that makes sense, thanks.

Bye, Jojo

[config.h (text/plain, attachment)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.