Thread: Re: Permission denied on fsync / Win32 (was right

Re: Permission denied on fsync / Win32 (was right

From
"Magnus Hagander"
Date:
> >> 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

Re: Permission denied on fsync / Win32 (was right

From
Tom Lane
Date:
"Magnus Hagander" <mha@sollentuna.net> writes:
> Because we are talking about checking the output from _commit(), right?
> (being fsync() redefined)

The failure could be coming from that, or from a preceding open() if the
bgwriter didn't already have the file open --- basically, the message
Peter is quoting indicates a failure return from FileSync() in fd.c.
The fact that it doesn't happen for him every time is pretty good
evidence that only one of those two cases fails.

            regards, tom lane