RE: bug#10305: coreutils-8.14, "rm -r" fails with EBADF

[Joachim Schmitz]

> From: Joachim Schmitz [mailto:address@hidden
> Sent: Wednesday, December 21, 2011 6:12 PM
> To: 'Eric Blake'; 'Jim Meyering'
> Cc: 'address@hidden'; 'Paul Eggert'; 'address@hidden'
> Subject: RE: bug#10305: coreutils-8.14, "rm -r" fails with EBADF
> 
> > From: Eric Blake [mailto:address@hidden
> > Sent: Wednesday, December 21, 2011 5:28 PM
> > To: Jim Meyering
> > Cc: Joachim Schmitz; address@hidden; 'Paul Eggert'; bug-
> > address@hidden
> > Subject: Re: bug#10305: coreutils-8.14, "rm -r" fails with EBADF
> >
> > On 12/21/2011 09:06 AM, Jim Meyering wrote:
> > >>
> > >> 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.
> 
> Yes, indeed, thanks for that idea (should have been mine):
> It got to be dd1, only it is not an fd but something called fnum and these a) 
> start
> counting with 1 rather than 0 and b) have 1 and 2 being root and CPD, followed

CWD I meant

> by 3,4 and 5 being stdin, stdout, stderr... it seems fnum -3 == fd
<snip>
> 
> So let's see whether taking that fnum (AKA "dd1") and subtracting 3 makes it a
> proper fd.
> But this is something for tomorrow...

Apparently an over simplistic approach: doesn't work, I still get an EBADF.

I tried in config.h:

#ifdef DIR_FD_MEMBER_NAME
# define DIR_TO_FD(Dir_p) ((Dir_p)->DIR_FD_MEMBER_NAME) 
#elif defined __TANDEM
# define DIR_TO_FD(Dir_p) (((Dir_p)->dd1) - 3)
#else 
# define DIR_TO_FD(Dir_p) -1 
#endif

Didn't work, unfortunately...