> Date: Mon, 27 Oct 2003 18:53:25 +0100
> From: =?UTF-8?B?QnJhbmtvIMSMaWJlag==?= <brane@xbc.nu>
> > The sleep should be sufficient to yield the CPU to the process
> > holding the file open so that it will finishing whatever it's doing
> > and close the file.
>
> That a) depends on what the other process is doing, and b) won't work on
> multiprocessor machines.
I was thinking of the case where the system is CPU-constrained, and a
sleep obviously frees up one of the CPUs. The sleep also helps
prevent a notebook computer from turning into a lap warmer. :-)
> > I would rather see the loop bounded by time - say five seconds -
> > rather than a fixed number of iterations.
>
> There's no real difference in practice -- both limits are arbitrary, and
> may work for some people but not for others.
>
> > Note that a bound is needed since the file may never become available.
> > The simplest way for anti-virus software to sequester a file is to
> > not close the file.
Some sort of bound is necessary since the delay required might be
infinite, i.e. the rename may never succeed.
A bound by iteration count is easier to implement, but a bound by time
leads to a more-predictable user experience.
> > The issue isn't atomicity but rather the Win32 API guarantee that a
> > file cannot be renamed or deleted while open.
>
> Win32 makes no such guarantee. A file _can_ be renamed or deleted while
> open, it just won't disappear from the directory listing until the last
> handle is closed. It would be amazingly simple to implement this if only
> Win32 offered a rename-through-handle function...
I tried this using Win32 calls, and if one process has a file open
a different process can neither rename nor delete it.
The operation fails and is not deferred (under XP anyway).
(if you have code that can do it, that's the solution to the problem)
> > One alternate solution would be to call the underlying NT API
> > directly, which can rename and delete open files. This does no good
> > for Win9x and would require use of many undocumented OS calls, but it
> > would allow the write-temp-rename-permanent method SVN uses.
>
> Yikes. That's all we need.
Indeed. It's hard to imagine ever wanting to do such a thing.
But, it could be done.
> >A more realistic alternative, if rename retries do not work, is to
> >change write methodology to a rename of the permanent name to a .BAK
> >and then writing the new data directly to the permanent name.
>
> This is dangerous. If the write can't complete, we're stuck with a
> clobbered working copy and no way to recover.
The working copy would probably have to have an "in progress" flag.
Reocovery would consist unwinding the previous changes - looking
for .BAK files - and perhaps keeping a log file to facilitate
partially-completed working copy changes.
Again, this has the virtue of being something that would work,
even if not a desirable solution.
If a loop with a 5-10 second bound results in no more bug reports then
more extreme methods won't be needed.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Oct 27 23:32:06 2003