From: Johannes Sixt Date: Tue, 16 May 2017 18:35:46 GMT Subject: Re: t5400 failure on Windows Message-ID: In-Reply-To: <20170515222406.hxab2wrapv75ybmj@sigill.intra.peff.net> Am 16.05.2017 um 00:24 schrieb Jeff King: > 4. There is something racy and unportable about both programs writing > to the same trace file. It's opened with O_APPEND, which means that > each write should atomically position the pointer at the end of the > file. Is it possible there's a problem with that in the way > O_APPEND works on Windows? > > If that was the case, though, I'd generally expect a sheared write > or a partial overwrite. The two origin/HEAD lines from the two > programs are the exact same length, but I'd find it more likely for > the overwrite to happen with one of the follow-on lines. Good guesswork! O_APPEND is not atomic on Windows, in particular, it is emulated as lseek(SEEK_END) followed by write(). I ran the test a few more times, and it fails in different ways (different missing lines) and also succeeds in a minority of the cases. Windows is capable of writing atomically in the way O_APPEND requires (keyword: FILE_APPEND_DATA), but I do not see a way to wedge this into the emulation layer. For the time being, I think I have to skip the test case. The question remains how endangered our uses of O_APPEND are when the POSIX semantics are not obeyed precisely: * trace.c: It is about debugging. Not critical. * sequencer.c: It writes the "done" file. No concurrent accesses are expected: Not critial. * refs/files-backend.c: There are uses in functions open_or_create_logfile() and log_ref_setup(). Sounds like it is in reflogs. Sounds like this is about reflogs. If there are concurrent accesses, there is a danger that a reflog is not recorded correctly. Then reflogs may be missing and objects may be pruned earlier than expected. That's something to worry about, but I would not count it as mission critical. -- Hannes