Paul Eggert wrote: > On 07/31/2012 09:07 AM, Jim Meyering wrote: >> I did something similar in gnulib's fts.c when deciding >> whether it needs to sort directory entries on inode number >> in order to avoid an O(N^2) seek storm. There, I used fstatfs >> to get each device's statfs.f_type, so far without complaint. >> Then, since we're using a file descriptor, there would be no race. > > For that purpose, a race isn't such a big deal, since it > merely causes fts to be slower. But for 'grep' > a race might cause the output to be incorrect, so we > need to consider it more carefully. > > I don't see how having a file descriptor avoids a race. > Using fstat gives us only a device+inode pair, right? > And if there's a unmount+mount between the time that we do the
fstat uses a file descriptor. Calling fstatfs on that same file descriptor should give a reliable (race-free) file system type. Since we're holding an open file descriptor, there should be little risk that the underlying file system will be unmounted. But if that does happen, any further attempt to use our now-stale file descriptor will probably fail with EIO, no? > fstat, and the time we check the file system, the > device number might not correspond to what's in the > mount table that we see, so we might get incorrect > information about the current file.
