Re: bug #17457: "grep -r foo . > somefile" goes into an infinite loop

[Paolo Bonzini]

On 07/26/2011 10:26 PM, Jim Meyering wrote:
> > >  I don't know about typical mingw file system usage.
> > >  Do mingw users use NTFS often?
> >
> >  Yes, all of them.  MinGW is just the name of the free compiler
> >  toolchain for Windows.  Unlike cygwin, it uses the MS C library, so
> >  anything MS documents applies to mingw.
>
> Bear in mind that cross-compiling mingw users often use ext3 and ext4,
> so any run-time test in a stat-like replacement function would affect
> them, too.

I don't understand this sentence. :)  What run-time test do you refer to?

First of all, some background.  Windows does have device and inode 
values, it just doesn't expose them via stat or fstat (or so says 
Microsoft, so you cannot trust the values anyway).  It also doesn't 
expose them via the Win32 equivalent of stat, but it does expose them 
via the Win32 equivalent of fstat.  gnulib would override fstat at no 
performance cost, with no run-time test and provide reliable 
st_dev/st_ino.  Overriding stat would have some performance cost and 
wouldn't be entirely reliable (the information is really not there in 
the Win32 equivalent of stat, only fstat; if opening the file fails, you 
cannot get reliable st_ino), but again wouldn't entail any run-time test.

Now, the final users of mingw executables are obviously running the 
program under Windows, and they're not going to use any Linux filesystem.

If you referred to cross-compiling users running tests on Wine, then: 1) 
it's up to Wine to implement Win32 APIs correctly so that they return 
correct device and inode values (and it does); 2) Wine's stat does not 
fill st_ino, but even if it did you wouldn't care about worse 
performance, because optimizing for a test environment makes no sense.

Paolo