Re: bug#8154: du: issue with `--files0-from=DIR'

[Eric Blake]

On 03/02/2011 10:10 AM, Paul Eggert wrote:
> On 03/02/2011 07:09 AM, Jim Meyering wrote:
>> -  struct argv_iterator *ai = malloc (sizeof *ai);
>> +  struct argv_iterator *ai;
>> +  struct stat st;
>> +
>> +  if (fstat (fileno (fp),&st) == 0&&  S_ISDIR (st.st_mode))
>> +    {
>> +      errno = EISDIR;
>> +      return NULL;
>> +    }
>> +
>> +  ai = malloc (sizeof *ai);
> 
> My kneejerk reaction is that this part of the patch
> should not be needed (though other fixes obviously are).
> There are lots of reasons that the stream could fail:
> why check for directories specially?

Because other GNU apps do so?  For example, POSIX requires that input
files to m4 must be text files.  If you do 'm4 dir/', you are therefore
violating POSIX, because dir/ is not a text file.  However, I've chosen
to make m4 uniformly fail with EISDIR on opening the file, rather than
deal with the vaguaries of different platforms (some forbid
fopen("dir/"), although that is in itself a POSIX violation; most get
past the fopen(), but then it's arbitrary whether the fread() sees EOF,
reads garbage, or fails with EISDIR).  See:
http://lists.gnu.org/archive/html/m4-patches/2008-09/msg00004.html
http://git.savannah.gnu.org/cgit/m4.git/commit?id=eed62f0d

>  Just let the
> stream fail in the way that it normally would; this
> keeps the code smaller and simpler.  On an ancient
> host where "cat dir/" works, "du --files0-from=dir/"
> should not arbitrarily fail.

Yes, the code would be simpler by letting the directory do what it
normally does (be that nothing, error, or raw data), but in the case of
raw data, acting on that garbage is likely to lead to a host of other
error messages.

-- 
Eric Blake   address@hidden    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature