This is one of the basic semantic differences for file behavior between
Windows and a unix-type OS, right? A unix OS allows the opening or
moving or deletion of files that are in use by another process
(ref-counting and inode thingies?), while Windows does not unless all
processes explicitly declare the sharing semantics when they open...I
think?
If that is true, then retrying is about the only way to handle it in
Windows, I guess, unless you can get all processes to cooperate. Haha.
I'm inclined to say it should go into Subversion rather than APR,
though, since apparently MS expects applications to do the retrying (or
they would do it in the APIs?)...but I have no strong feelings. I will
probably take a shot at a patch for svn_io_file_rename later tonight or
tomorrow, if no one else wants to.
DJ
-----Original Message-----
From: Kevin Pilch-Bisson [mailto:kevin@pilch-bisson.net]
Sent: Thursday, May 22, 2003 9:52 AM
To: dev@subversion.tigris.org
Subject: Re: svn.collab.net is now running Subversion 0.23.
Here's a quote I got about the subject:
"even without a virusscanner, you just can't assume that you're the only
component interested in a file. You "must" write your code with the
assumption that there will be a sharing violation when you try to open
the
file. Indexing service, disk defragmenter, backup software, etc are all
possibilities."
Looks like the best approach would be to trap the error, and retry.
(Given
this argument, I might argue that it belongs in APR too.)
**********************************************************************
This email and any files transmitted with it are confidential
and intended solely for the use of the individual or entity to
whom they are addressed. If you have received this email
in error please notify the system manager.
This footnote also confirms that this email message has been
swept by MIMEsweeper for the presence of computer viruses.
www.mimesweeper.com
**********************************************************************
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri May 23 01:40:33 2003