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 d
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 ra
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 appar
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 c
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 sit
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.
-Rob
On Fri, 10 Jan 2003, Steve Barber wrote:
> I'm submitting a message from one of my co-workers who's not
> subscribe
