Delayed folder delete unatomic?

[Janne Peltonen]

Hi!

Running murder here, with delayed folder deletion. After upgrading to 2.4.12
last year, I've seen sporadical problems with delayed folder deletion: I get
two instances of the deleted folder in the DELETED hierarchy, with the
timestamp (ie. last part of folder name) slightly apart, with only the later
folder getting actually created in the filesystem. Like this:

DELETED.user.hjlaakso.roskis.51063101
DELETED.user.hjlaakso.roskis.5106310B

After this, if Cyrus tries to access DELETED.user.hjlaakso.roskis.51063101, it
gets an IO error (since the folder doesn't actually exist). The folder
DELETED.user.hjlaakso.roskis.5106310B does exist, and has the contents of the
folder it should have.

The easiest way to work around the problem is to reconstruct the folder using,
well, reconstruct. This appears to create the necessary directories and files
on disk (empty, of course, but this isn't such a big deal because the contents
of the folder are already in the other DELETED.blah folder).

But when we add replication to the mix, it gets a bit annoying, since
replication gets stuck on the ioerror and synclog starts growing...

Anyone else seen this?


--Janne
-- 
Janne Peltonen <janne.peltonen at helsinki.fi> PGP Key ID: 0x9CFAC88B
Please consider membership of the Hospitality Club (http://www.hospitalityclub.org)