[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Removing a directory gets stuck

From: Branko Čibej <brane_at_apache.org>
Date: Mon, 22 Feb 2016 22:19:45 +0100

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
Received on 2016-02-22 22:19:54 CET

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.