bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Eric Blake
Subject: Re: rm (remove.c): Rewrite to use fts: request for review
Date: Thu, 03 Sep 2009 22:43:25 -0600
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.23) Gecko/20090812 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Eric Blake on 8/28/2009 3:40 PM:
> Also, mingw does not provide dirfd and its struct DIR does not have room for 
> an 
> fd, so gnulib's dirfd replacement currently just returns ENOTSUP (as 
> permitted 
> by POSIX).

fts handles this okay (by devolving gracefully into slower algorithms),
but other clients don't.  For example, on coreutils' master branch,
remove.c blindly assumes that it can call
openat(dirfd(dirp),"..",O_RDONLY), which is not true (on coreutils' next
branch, this code is deleted).  At this point, since fdopendir is already
GPL, I don't see a reason to create any new module; rather, I'll just work
on improving the existing module to a) guarantee that dirfd(dirp) works,
even on mingw after plain opendir, and b) where dirfd already works,
guarantee that dirfd(dirp) returns the same fd as handed to fdopendir
(either by writing back into the dirent->d[d]_fd member on platforms where
it is accesssible, or by dup/close'ing the user's fd out of the way, then
calling opendir(".") as many times as necessary until dirfd gives the
right answer, and cleaning up the mess).

- --
Don't work too hard, make some time for fun as well!

Eric Blake             address@hidden
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkqgmu0ACgkQ84KuGfSFAYCaRgCg15hwz1YjpEbqvsL7e4QuNkGw
89YAoIYcyzZFf3sudb+Rj4d6UuXL+050
=0HqN
-----END PGP SIGNATURE-----




reply via email to

[Prev in Thread] Current Thread [Next in Thread]