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.
