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@xxxxxxxxxxx> PGP Key ID: 0x9CFAC88B Please consider membership of the Hospitality Club (http://www.hospitalityclub.org) ---- Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
