subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Branko Čibej <br...@apache.org>
Subject Re: Removing a directory gets stuck
Date Mon, 22 Feb 2016 21:19:45 GMT
On 22.02.2016 14:26, Niemann, Hartmut wrote:
>
> Hello!
>
>  
>
> I use TortoiseSVN (1.9.3) on Windows 7 and observe the effect that
> deleting (svn rm or move) a directory
>
> about once in four attempts fails with something along “could not
> remove directory
>
> because it was not empty”.
>
>  
>
> I suspect that the virus scanner stands in the way, because when I
> look the directory is empty, and
>
> a cleanup process almost always succeeds.
>
>  
>
> Can the directory removal be made more robust (like: if it fails and
> shouldn’t, just wait a second and retry,
>
> and *then* complain)
>

This is what Subversion already does. Windows virus scanners are
notoriously flaky, buggy and broken; we've had Windows-specific retry
logic in the code almost from day one because of that, and the back-off
and retry can be longer than one second. The fault is squarely at the
door of virus scanner developers; they're supposed to be invisible to
the user but the majority do not preserve filesystem semantics.

> or be de-interlaced from the database operation, removing the entry in
> the
>
> working copy, closing the database and after that issuing the remove
> and rmdir commands on the
>
> file system?
>

This would be a great way to randomly break working copies. The on-disk
state and the database contents have to be in sync; we go to a lot of
trouble to make sure they are. Decoupling database changes from
filesystem changes would pretty much guarantee that /any/ problem,
transient or otherwise, with the disk or filesystem would leave the
working copy irretrievably broken.


-- Brane


Mime
View raw message