Philip Martin wrote:
>Branko ÄŒibej <brane@xbc.nu> writes:
>
>
>
>>Philip Martin wrote:
>>
>>
>>
>>>Branko ÄŒibej <brane@xbc.nu> writes:
>>>
>>>
>>>
>>>>Which suggests a simple solution, using the following (Windows-specific)
>>>>algorithm:
>>>>
>>>> 1. open temp (no sharing)
>>>> 2. write contents to temp
>>>>
>>>>
>>>Need some sort of flush of temp before deleting orig (if it was Unix).
>>>
>>>
>>>
>>:-) Read on...
>>
>>
>>
>>>> 3. delete orig
>>>> 4. rename temp to orig
>>>> 5. close temp
>>>>
>>>>
>>>Suppose the close fails, are there any guarantees about the state of
>>>the working copy?
>>>
>>>
>>>
>>There's no guarantee that everyhing has been written to disk even if
>>close succeeds, since (at least on NTFS) actuall disk space commit
>>happens during cache flush. The only way to guarantee that everything is
>>on disk before the close is to flush the file buffers (or open the file
>>in write-through mode) -- and that's true of the current implementation,
>>too.
>>
>>
>
>I don't think we use fsync so the current Unix implementation doesn't
>guarantee that data has hit the disk either. I'm not sure that any
>implementation can guarantee that if the working copy is on NFS. What
>the current Unix implementation does guarantee (I think) is that the
>data is not cached by the process, it's been handed off to the OS, so
>unless the OS crashes it will get written to disk at some stage.
>
>
Ah, yes. Well, a flush at the right place won't hurt then.
--
Brane Čibej <brane_at_xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Oct 28 00:10:56 2003