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 ...