Re: [PATCH] Add a new lstat and fstat implementation based on Win32 API

> On Mon, 3 Sep 2007, Marius Storm-Olsen wrote:
>> There was a problem with racy conditions, which this revision fixes.
>> The problem was that fstat was using the builtin implementation, which for
>> for some reason is off by some amount of seconds. (This is probably due to
>> some leap-year issue in one of the implementations. However, Microsoft tells
>> us to use 116444736000000000 in http://support.microsoft.com/kb/167296, so
>> I'll stick with that.)
>> Also, since both stat and lstat proved to be rather slow, having our own
>> version of fstat is probably also wise. At least we now control all the
>> stat'ing, so we _know_ they are compatible.
>> Also note that this revision makes git_lstat call itself after modifying
>> the filename, instead of the builtin stat, for the same reasons.
> 
> At least some of these informations should go into the commit message, 
> too.

>> With the our own implementations of lstat & fstat, the following test cases
>> are now fixed:
>>     t4116-apply-reverte.sh
>>         ok 3: apply in reverse
>>     t4200-rerere.sh
>>         ok 17: young records still live
>> However, the following test cases seems to fail now:
>>     t6024-recursive-merge.sh
>>         FAIL 1: setup tests
>>         FAIL 3: result contains a conflict
>>         FAIL 4: virtual trees were processed
>>         FAIL 5: refuse to merge binaries
>>
>> See attached test case logs.
>> Are some of these test cases unstable, so the result will fluctuate on
>> Windows?
> 
> I saw some funny stuff on Windows, like test cases succeeding when run 
> interactively, but failing when run from "make test".