> >> Is it possible that we are getting EACCES (ERROR_SHARING_VIOLATION > >> maybe) in the situation where we try to fsync a file that's been > >> unlinked but isn't fully gone yet due to open handles? > > > I think that sounds "reasonable". Not as in a reasonable > thing to do, > > but as a reasonable thing to expect from the win32 api. > > Probably be good if someone can experimentally confirm that > (and confirm exactly which underlying Win32 error code it is) > before we think about how to fix it.
Hmm. A very simple test that's basically: A: open file (using win32_open copied from src/port) A: fsync file (success) B: delete file A: fsync file again (success) So it must be a different scenario that causes it. Per the MSDN docs (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclib/ html/_crt__commit.asp) the result code sohuld be EBADF and nothing else - which is clearly not what's happening :-( Because we are talking about checking the output from _commit(), right? (being fsync() redefined) //Magnus ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
