> If your fix works, I will change the Win32-specific code to use open()
> and fdopen(). The only advantage to the old code was that it would
> release locks, then go into a rename loop, which is horid, and we need
> to avoid the loop.
Ah, I see. Should've been obvious you had that in mind actua
Claudio Natoli wrote:
>
> > main file. WIth Claudio's fix, this isn't necessary.
>
> Bruce, are you sure this is true? The fix is only for files than are
> open()'d, not fopen()'d (as per AllocateFile).
If your fix works, I will change the Win32-specific code to use open()
and fdopen(). The on
> main file. WIth Claudio's fix, this isn't necessary.
Bruce, are you sure this is true? The fix is only for files than are
open()'d, not fopen()'d (as per AllocateFile).
Cheers,
Claudio
---
Certain disclaimers and policies apply to all email sent from Memetrics.
For the full text of these di
Claudio found that his new delete fix for Win32 also works for rename on
files open by other processes, so I have applied the following patch to
remove the special rename() handling on Win32. What it used to do was
to rename a file to a *.new, release locks, then do the rename to the
main file. W
