Re: rm (remove.c): Rewrite to use fts: request for review

[Jim Meyering]

Eric Blake wrote:
> Jim Meyering <jim <at> meyering.net> writes:
>> It'd be great if another pair of eyes could glance through
>> these changes (diffs look "big", but most hunks are simply removals).
>
> I haven't looked at this closely yet, but one thing raised a question in my
> mind: with the switch to fts, can 'rm -ri dir <&-' ever see fd 0 tied to an
> open directory when querying, or does the first query still occur before any 
> fd
> is created?  If the former, that lends more urgency to my goal of implementing
> opendir_safer.

So far, at least with native openat, it looks like we're ok.  The first
file descriptor we obtain via fts (fd=0 in that scenario) is the result
of an openat syscall, and we use that to read the dir entries of the
just-opened dir, and then close it.  Then control moves back into
remove.c, where we call prompt, which tries to read from the closed
STDIN_FILENO.

However, regardless of whether some existing tool happens to trigger
the problem, it's bound to happen sooner or later.  It'd be a mistake
*not* to add and use opendir_safer.

> In looking at gnulib, I noticed that fdopendir is hidden inside openat.c, and
> is rather inefficient on mingw when the fchdir module is also in use (since 
> the

I confess I have not been concerned with efficiency on mingw or any other
system that is so far removed from POSIX.  My main goal in providing
the openat emulation was to make it so applications can code to these
useful system interfaces (the *at functions).

> fchdir module maintains a name/fd mapping, we could just refer to that for the
> proper opendir() invocation rather than wasting save_cwd/fchdir/opendir
> (".")/restore_cwd.  I guess my first course of action will be moving fdopendir
> into its own module, along with creating unit tests for fdopendir and fchdir.

Sounds like a good idea.
mingw is a useful platform.
It's good that you're inclined to help it along.

> Also, mingw does not provide dirfd and its struct DIR does not have room for 
> an
...