Kevin Puetz wrote:
> <politics>
> The directory case is particularly nasty in that even paths which are not
> marked for backup are affected, so the interaction isn't obvious
> (apparently it does the readdir, then filters the list of filenames). IS
> certainly tried to pin it on our use of a buggy 'freeware' program. If I
> hadn't had enough knowledge to get to the bottom of it and *prove* that it
> was Veritas at fault with filemon traces involving multiple programs, they
> might have succeeded.
>
> If you can't tell, the relationship betwen Corporate IS and actual users has
> gotten rather ugly and adversarial. Oh well...
> </politics>
>
> <technical>
> I'd certainly welcome it 'just working', but the problem is the combination
> of exclusive opens, and all the stupid follow-along software on win32, so
> it probably needs to be worked around all the way at the bottom - every
> file or directory unlink call is subject to this sort of failure mode. So
> the place to work around it is probably apr. Note that the delays involved
> might be *very* long - DLOClient will actually try to transmit the file
> contents, over the network, to the backup server, before it closes the
> file. I wonder if there's some way to determine what program has the file
> open when we go to retry, so that the error message could implicate the
> offender if we dinally do time-out.
> </technical>
There's a neat little hack called "ForceDel" which will delete locked
files under Windows.
A similar hack could be used to delete files in use by DLOClient or
other ill-designed software.
The trick is to search for processes which are using the file(s) we
need to delete, then start a thread in those processes (using
CreateRemoteThread). These threads can then close the problematic
handle(s) in those processes.
It will invalidate the handles in the process(es) affected, so they
might not like it much.
But it will also work around the problem and fix the problematic
situation you quoted in #politics.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Apr 4 09:45:25 2005