Re: fsync with sync, and Win32 unlink

Tom Lane wrote:
> Claudio Natoli  writes:
> > Tom Lane wrote:
> >> However, I don't see exactly how that can win?
> 
> > Why not?
> 
> More like "why?".  The problem we have is with making sure that existing
> files we don't want anymore will go away in a timely fashion.  I don't
> see how it helps to modify file creation to allow overwrite.  We are not
> (in most deletion cases) expecting anyone to re-create that file later.
> 
> [snip]
>
> So unless I'm totally misunderstanding where you mean to use 
> this code, I don't see the point.

I think you might be.

I'm not suggesting that we modify file creation to allow overwrite. The
suggestion is that we modify file creation to allow delete. Win32 _open()
call opens files in a manner that does not allow them to be deleted when
held by another process. However, "replacing" the open() call with an
orchestrated call to CreateFile/_open_osfhandle appears to give us exactly
that behaviour we expect from open() under *nix (specifically, being able to
unlink a file held by another process).

Am we talking at cross-purposes here?

Cheers,
Claudio


--- 
Certain disclaimers and policies apply to all email sent from Memetrics.
For the full text of these disclaimers and policies see 
http://www.memetrics.com/em
ailpolicy.html