> >> 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=20
> >> unlinked but isn't fully gone yet due to open handles?
>=20
> > I think that sounds "reasonable". Not as in a reasonable=20
> thing to do,=20
> > but as a reasonable thing to expect from the win32 api.
>=20
> Probably be good if someone can experimentally confirm that=20
> (and confirm exactly which underlying Win32 error code it is)=20
> 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=3D/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
