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

Previous Next

Full log

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

From: Jim Meyering <jim <at> meyering.net>
To: "Joachim Schmitz" <jojo <at> schmitz-digital.de>
Cc: 10305 <at> debbugs.gnu.org, 'Paul Eggert' <eggert <at> cs.ucla.edu>,
	bug-gnulib <at> gnu.org
Subject: Re: bug#10305: coreutils-8.14, "rm -r" fails with EBADF
Date: Wed, 21 Dec 2011 17:06:41 +0100

Joachim Schmitz wrote:
...
> Hmm DIR_TO_FD() is :
> #define DIR_TO_FD(Dir_p) -1
>
> In config.h:
> /* the name of the file descriptor member of DIR */
> /* #undef DIR_FD_MEMBER_NAME */
>
> #ifdef DIR_FD_MEMBER_NAME
> # define DIR_TO_FD(Dir_p) ((Dir_p)->DIR_FD_MEMBER_NAME)
> #else
> # define DIR_TO_FD(Dir_p) -1
> #endif
>
> So fd_clone_dir() does not return NULL, but has errno set to ENTOSUP.
>
>
> Our "struct DIR" has 2 shorts and one long, with funny names dd1, dd2
> and dd3... looking at their content: nothing looks like a proper fd
> (values 7, 257 and 135067072, respectively)
>
>
> Where to go now?
>
> Resorting to wild guesses, I tried all 3 members of struct DIR as
> DIF_FD_MEMBER_NAME, no change to the EBADF

Write a small test program that opens say four directories,
to get one DIR* pointer for each.  Then print a table of
the DIR member values.  Maybe you'll see a pattern, i.e.,
how to derive an FD number from those dd1,2,3 fields.

Previous Next

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