Removing a directory gets stuck

["Niemann, Hartmut" <ha...@siemens.com>]

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) 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?

Mit freundlichen Grüßen
Dr. Hartmut Niemann

Siemens AG
MO MLT LM EN CCI 1
Werner-von-Siemens-Str. 67
91052 Erlangen, Deutschland
Tel.: +49 9131 7-34264
Fax: +49 9131 7-26254
mailto:hartmut.niemann@siemens.com

Siemens Aktiengesellschaft: Vorsitzender des Aufsichtsrats: Gerhard Cromme; Vorstand: Joe Kaeser, Vorsitzender; Roland Busch, Lisa Davis, Klaus Helmrich, Janina Kugel, Siegfried Russwurm, Ralf P. Thomas; Sitz der Gesellschaft: Berlin und München, Deutschland; Registergericht: Berlin Charlottenburg, HRB 12300, München, HRB 6684; WEEE-Reg.-Nr. DE 23691322

Re: Removing a directory gets stuck

[Branko Čibej <br...@apache.org>]

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