Re: delete selected folder leaves empty dir on disk
On Fri, 10 Jan 2003, Rob Siemborski wrote: On Fri, 10 Jan 2003, John Alton Tamplin wrote: Since rmdir() doesn't delete it, I assume that means there is some entry Well, on linux atleast, rmdir() can fail with EBUSY: EBUSY pathname is the current working directory or root directory of some process. On solaris, you do have to be the process selected on the mailbox to hit the problem. There are two ways to fix this: 1) Don't cd to the directory (this fixes the EBUSY problem) 2) Put a tombstone there, and clean up the directory later. I like (2) a lot more, and it is in tone with http://bugzilla.andrew.cmu.edu/show_bug.cgi?id=1297 http://bugzilla.andrew.cmu.edu/show_bug.cgi?id=1268 -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh
delete selected folder leaves empty dir on disk
I'm submitting a message from one of my co-workers who's not subscribed directly to the list... Original Message Subject: delete selected folder leaves empty dir on disk Date: Wed, 08 Jan 2003 13:26:24 -0500 From: Christopher Schanzle [EMAIL PROTECTED] To: [EMAIL PROTECTED] This isn't a huge problem, but it would be nice to get cleaned up if possible. Occasionally we have discovered empty directories in a user's spool area. Empty means no cyrus.* files, or messages. They are not in the mailbox.db as a current mailbox. I have discovered that if the folder to delete is first selected, all files are removed (including cyrus.*), it is removed from the mailbox db, but the (empty) directory remains on disk. I've also duplicated this by just telnetting to the imap port, created a folder, selected it, then deleted it. The directory remained. What I have found is the directory does not remain if the folder is not selected before the delete. Here's a log of the one that leaves a directory: -- schanzle Wed Jan 8 12:38:34 2003 10420475142 select INBOX.newfolder 1042047514* FLAGS (\Answered \Flagged \Draft \Deleted \Seen) * OK [PERMANENTFLAGS (\Answered \Flagged \Draft \Deleted \Seen \*)] * 0 EXISTS * 0 RECENT * OK [UIDVALIDITY 1042047507] * OK [UIDNEXT 1] 2 OK [READ-WRITE] Completed 10420475143 getacl INBOX.newfolder 1042047514* ACL INBOX.newfolder schanzle lrswipcda cyrusadm lrswipcda anyone p3 OK Completed 10420480464 list INBOX.newfolder.* 10420480464 OK Completed (0.000 secs 1 calls) 10420480465 close 10420480465 OK Completed 10420480466 delete INBOX.newfolder 10420480476 OK Completed 10420480477 unsubscribe INBOX.newfolder 10420480477 OK Completed 10420480768 logout 1042048076* BYE LOGOUT received 8 OK Completed Log of one that does NOT leave a directory (never selected): -- schanzle Wed Jan 8 12:52:33 2003 10420483532 list INBOX.foobar.* 10420483532 OK Completed (0.000 secs 1 calls) 10420483533 delete INBOX.foobar 10420483533 OK Completed 10420483534 unsubscribe INBOX.foobar 10420483534 OK Completed 10420483715 logout 1042048371* BYE LOGOUT received 5 OK Completed name : Cyrus IMAPD version: v2.1.11 2002/12/04 14:53:12 vendor : Project Cyrus support-url: http://asg.web.cmu.edu/cyrus os : SunOS os-version : 5.8 environment: Cyrus SASL 2.1.10 Sleepycat Software: Berkeley DB 4.1.24: (September 13, 2002) CMU Sieve 2.2 TCP Wrappers mmap = shared lock = fcntl nonblock = fcntl auth = unix idle = idled dirhash = full mboxlist.db = skiplist subs.db = flat seen.db = skiplist duplicate.db = db3-nosync tls.db = db3-nosync
Re: delete selected folder leaves empty dir on disk
On Fri, 10 Jan 2003, John Alton Tamplin wrote: So is it ok to sweep the filesystem and delete any empty directories? Would that leave a race condition with an imapd creating a new folder? Yes, it could. It seems like it should be safe to rmdir() the directory even if some process is sitting on it or has it open -- there might need to be additional error checking to handle a directory disappearing unexpectedly, but that doesn't seem to be a big problem. We do currently call rmdir() on the directory. The applicable code is in mailbox_delete() in mailbox.c if you'd like to suggest a patch. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper
Re: delete selected folder leaves empty dir on disk
Rob Siemborski wrote: Yeah, we know about this. There's no good way around it, since a totally separate imapd could be selected on the folder as well, and the directory would still be left around. So is it ok to sweep the filesystem and delete any empty directories? Would that leave a race condition with an imapd creating a new folder? It seems like it should be safe to rmdir() the directory even if some process is sitting on it or has it open -- there might need to be additional error checking to handle a directory disappearing unexpectedly, but that doesn't seem to be a big problem. -- John A. Tamplin Unix System Administrator Emory University, School of Public Health +1 404/727-9931
Re: delete selected folder leaves empty dir on disk
Rob Siemborski wrote: We do currently call rmdir() on the directory. The applicable code is in mailbox_delete() in mailbox.c if you'd like to suggest a patch. Since rmdir() doesn't delete it, I assume that means there is some entry in the directory which wasn't deleted. Since you have apparently looked at this before, what is the cause? Is unlink failing on some file for some reason, or is it a race condition of a file being created after the opendir() and before the rmdir() loop? This has been particularly annoying here during the conversion, because Mail::IMAPClient uses temporary folders and it deletes them while they are selected, leaving thousands of empty top-level directories. I shut the server down and cleaned them up, but that isn't something I would like to do often. -- John A. Tamplin Unix System Administrator Emory University, School of Public Health +1 404/727-9931
Re: delete selected folder leaves empty dir on disk
On Fri, 10 Jan 2003, John Alton Tamplin wrote: Since rmdir() doesn't delete it, I assume that means there is some entry in the directory which wasn't deleted. Since you have apparently looked at this before, what is the cause? Is unlink failing on some file for some reason, or is it a race condition of a file being created after the opendir() and before the rmdir() loop? Well, on linux atleast, rmdir() can fail with EBUSY: EBUSY pathname is the current working directory or root directory of some process. On solaris, you do have to be the process selected on the mailbox to hit the problem. This has been particularly annoying here during the conversion, because Mail::IMAPClient uses temporary folders and it deletes them while they are selected, leaving thousands of empty top-level directories. I shut the server down and cleaned them up, but that isn't something I would like to do often. I actually suspect its easier to fix Mail::IMAPClient than to get a totally correct cyrus. The bug for this issue is here: http://bugzilla.andrew.cmu.edu/show_bug.cgi?id=1268 -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper
