Re: Bug: tests/fsync.c: don't check for fsync failure on invalid fd

[Eric Blake]

On 03/14/2013 11:45 AM, Phillip Susi wrote:
> On 3/14/2013 12:49 PM, Paul Eggert wrote:
>> On 03/14/13 07:24, Phillip Susi wrote:
>>>> MIT Kerberos relies on fsync (invalid_fd) returning -1, so I
>>>>> suppose it's worth the bother.
>>> It does?  How so?
> 
>> Just grab the source and grep for 'fsync'; you'll find it checking
>> for EBADF afterwards, in at least one place.
> 
> Just because it checks for it does not mean that it depends on it.
> The question is does it break when run with eatmydata?  Does it break
> when built with eatmydata?
> 
> A cursory check of the source code indicates that it does not, and the
> only way I can see it could in theory is if it regularly tried to
> fsync an invalid fd, and would do something bad if it didn't get told
> that it had some something stupid ( fsync an invalid fd ).  If not,
> then it doesn't depend on it so would not care if gnulib stopped
> complaining about it.  For that matter, it doesn't appear to even use
> gnulib, so couldn't care one way or the other.

You seem to think that just because gnulib's test-fsync fails, that the
entire package fails.  Really, test-fsync is just a unit test, and you
are free to ignore its results, when those results are just confirming
the obvious - that libeatmydata is not POSIX-compliant.

It's probably not worth patching gnulib's testsuite to work around
libeatmydata, but we have already told you how you may patch
libeatmydata to be slightly more friendly to gnulib's testsuite.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature