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

From: Paul Eggert <[email-masked]>
Date: Mon, 19 Dec 2011 09:28:39 -0800

On 12/19/11 00:11, Joachim Schmitz wrote:
> So it [opendirat] goes into fdopendir(), fdopendir_with_dup(), rpl_dup(),
> the real dup() (disguised as dup_nothrow(), with success), _gl_register_dup(),
> nothing but success, no suspicious activity against fd.
> 
> Then it [fdopendir_with_dup] calls close(3) !!!

Yes, that's what I'd expect.  fdopendir_with_dup sees that fd is 3
and dupfd is 4.  So it invokes close (3) and then fd_clone_opendir (4, ...)
because it wants fd_clone_opendir to open a file (getting fd 3) and
then operate on fd 3.

then close(4) (the fd from the dup())  errno set to ENOTSUP

Sorry, you've jumped ahead too fast for me to follow.  As I understand
it, fd_clone_opendir (4, ...) should first try openat_proc_name (..., 4, "."),
which should fail; it should then try _gl_directory_name (4),
and this should return the name "D" of the directory.  fd_clone_opendir
should then invoke opendir ("D"), which should then open the directory,
internally get file descriptor 3, and then return a nonnull DIR *
pointer that is based on file descriptor 3; this is the value that
fd_clone_opendir should return back to fdopendir_with_dup.

So when fdopendir_with_dup later does that close(4), it should be OK.
since the directory is still open on file descriptor 3.

When you say that errno is set to ENOTSUP, though, that suggests
that my analysis is wrong and fd_clone_opendir returns NULL with
errno == ENOTSUP.  Can you please investigate why that might be?

On 12/19/11 05:22, Joachim Schmitz wrote:
> Trying to spot the relevant diff between the two and relating them to the problem I have in coretuils:

I suppose you might try applying the reverse of those patches
to coreutils 8.14 to see whether it fixes the problem.  I don't
hold out much hope for that approach, though.