Re: gnulib broken on systems lacking fchdir

[Eric Blake]

Matthew Woehlke <mw_triad <at> users.sourceforge.net> writes:

> That sounds like a good idea, but... does that mean I have to *write* an 
> entire unistd.h *and* make it work everywhere, or is there a way to 
> 'drop in' one that pulls the system unistd.h, plus extras?

For an example of how to provide a replacement <unistd.h>, see how gnulib 
already provides a replacement <sys/stat.h> which pulls in the system version, 
then touches it up as needed.  You would really be writing lib/unistd_.h, which 
first includes @ABSOLUTE_UNISTD_H@, then, if HAVE_FCHDIR is not defined, 
replaces fchdir with rpl_fchdir, etc.

> 
> As mentioned, so far this has nothing to do with coreutils except that I 
> know it *will* affect coreutils. Right now I'm worrying about gzip.  
> But... I'm also planning on building gettext (albeit not a version that 
> has the newer *at stuff AFAIK).

To my knowledge, gettext does not depend on fchdir (as evidenced by the fact 
that it builds on mingw).  But coreutils, findutils, tar, and gzip all use 
gnulib directory traversal.

> 
> Back to the technical standpoint, come to think of it don't most systems 
> limit # of fd's to a reasonable number like 1024? 

No, the GNU spirit is to avoid arbitrary limits, and 1024 is arbitrary (on the 
other hand, perhaps you can convince us that all platforms that lack fchdir 
also have a known compile-time OPEN_MAX?).  Instead, I would make it a malloc'd 
array, perhaps defaulting to something like 16 elements (after all, the fts 
philsophy currently only keeps an i-ring of recently open directory fds, with 
the ring size currently set to 4), and grow the size of the array if an fd is 
encountered larger than the current array size.  And remember, the array is not 
likely to be sparse, since open() is required to return the lowest-available fd 
(and even if the *-safer modules are in effect, you still get the lowest-
available fd greater than 2).

As for an audit of uses of fchdir in gnulib, here is my preliminary analysis:

at-func.c and openat.c use fchdir on arbitrary fds.  It would take an audit of 
coreutils to see if it uses any of the *at functions raw, or whether it always 
goes through the fts interface; depending on that audit, you may have to 
override fileno, fopen, etc.

chdir-long.c, fts.c, save-cwd.c, and savewd.c all look like self-contained 
implementations (ie. the only fds they hand to fchdir are ones they opened 
themselves, rather than an fd from arbitrary code), and it looks like the 
following functions need hooks for fchdir tracking to work: openat, close, 
open, open_safer, opendirat, opendir, and dirfd.  Again, if you do things 
right, correct usage of <config.h> and a replacement <unistd.h> can make all 
these other gnulib files work without needing any code edits.

For that matter, if you implement fchdir, then save-cwd.c can be simplified, 
since it is currently catering to platforms that lack fchdir.

-- 
Eric Blake