[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Windows XP "Access denied" svn_io_rename

From: Philip Martin <philip_at_codematters.co.uk>
Date: 2003-10-28 00:04:10 CET

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.

-- 
Philip Martin
---------------------------------------------------------------------
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:04:59 2003

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.