Google turns up a few past discussions of this symptom, but the analysis
is incorrect - that it's the fault of a virus scan or other interfering
Symptom: Doing svnadmin load gives:
svnadmin: Can't remove 'D:\repos\bfc\db\transactions\1768-1.txn': The
directory is not empty.
When you look, the directory is not only empty - it's usually even been
I strongly suspect it occurs in other contexts as well, but svnadmin
load is where we do thousands of commits in a short time...
This is a problem that Subversion shares with many, many other tools -
ClearCase, Eclipse, ant, and even the Windows explorer. Eclipse has
recently taken steps in some (but not all) places to deal with it,
prompted by a report that it happens more often on Vista. This, after
years of beating my head against the wall looking for interfering
processes, finally led me to the light...
On Windows, DeleteFile is NOT SYNCHRONOUS; it marks the file for
deletion after all IO ceases and all handles are closed. This means that
if you delete all the files in a directory, and then delete the
directory, it will SOMETIMES FAIL.
Add to this that processes scanning directories for indexing, virus
protection, backup, and other purposes are part of the basic ecosystem,
and it is clear: the code should be prepared for deletion of the
directory to fail, and to retry a short time later.
This is a real pain. In my case, a repository move that should have
taken a few hours overnight in a single step is turning into a manual
nightmare, with a greatly increased risk I'll make a typo and drop
revisions or something.
I really think this needs to be tracked as a Subversion bug, tested for,
But I'm sending email first, since you've got that Big Yellow Buddy
System warning, and maybe it's in there some way I didn't manage to turn
up in my searches.
Received on Thu May 31 01:03:29 2007