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

[Jim Meyering]

Eric Blake wrote:
> 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

That's fine for m4, but the --files0-from argument
is a file containing NUL-delimited file names: not a text file.
And obviously not covered by POSIX, besides.
However, my primary motivation was this: if we special-case
directories, should we also special-case char- and block-devices?
That seems inappropriate.

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