On 2/18/14, 12:22 PM, Johan Corveleyn wrote:
> Thanks for the hint. Now, this wasn't an error path (just a commit
> that should have succeeded and should've written something to stdout).
> I'm not sure how I can determine that this is the likely cause ... I
> can't seem to reproduce it, no matter how hard I try :-(.
I unfortunately don't have any good suggestions. However, I'm assuming we made
the change to flush stdout when there wasn't an error for some good reason.
> Bert also suggested another possible reason: perhaps it was no
> flushing problem, but rather that the commit didn't do anything
> because the commit crawler didn't find any mods (perhaps because of
> timestamp granularity stuff). If my ramdisk would have been a FAT32
> partition, that might be a possible explanation, but "unfortunately"
> it's an NTFS ramdisk ... I don't see how this could have happened.
> Perhaps someone can hypothesize something, and talk me through a
> possible scenario?
NTFS itself has 100 nanosecond resolution, but I don't believe you can actually
achieve that resolution with Windows XP. See:
http://www.infosec.jmu.edu/documents/jmu-infosec-tr-2009-002.pdf
That paper shows that Windows XP was only capable of providing 1600 nanosecond
resolution.
I don't know if this is enough to drive the issue you're seeing. But it's
useful to realize that NTFS's storage capability doesn't reflect the actual
accuracy of timestamps in practice.
Received on 2014-02-18 21:41:11 CET