Re: readdir loses renamed files

[Timo Sirainen]

On 25.10.2004, at 11:29, Chris Wedgwood wrote:

> On Mon, Oct 25, 2004 at 04:21:57AM +0300, Timo Sirainen wrote:
>
> > My problem is that mails in a large maildir get temporarily
> > lost. This happens because readdir() never returns a file which was
> > just rename()d by another process. Either new or the old name would
> > have been fine, but it's not returned at all.
>
> i don't think there are well defined semantics for this, it's
> intrinsically hard to make it work the way you want for a number of
> reasons (and what they are depends on the underlying fs)

Thought so. Maybe reiser4 would work?

> > so I'll have to implement some extra locking anyway (so much for
> > maildir being lockless), but it would be nice to have at least one
> > OS where it works without the extra locking overhead.
>
> why do you need extra locking?  the next time the maildir is scanned
> the message(s) will appear surely?

So if I lose a file, how many times should I scan the directory again 
to know if it's really gone? And is it really worth the extra overhead 
when it's hardly ever needed? I'd rather not knowingly build software 
that works only in optimal conditions.

The test program that I had showed that the next scan didn't 
necessarily return it either. The file was sometimes lost for as long 
as 5 scans.

Of course I could just accept that messages go away and come back 
again, but it's not very nice for an IMAP server to do. Some clients 
attach metadata to messages based on their IMAP UID, so that would be 
lost.

I guess one solution would be to use one of the dnotify's replacements 
which tells which files were added, removed or renamed. Then readdir() 
would be needed only when mailbox is being opened.

Attachment: PGP.sig
Description: This is a digitally signed message part