lkml.org 
[lkml]   [2004]   [Oct]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: readdir loses renamed files
Date
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.
[unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2005-03-22 14:07    [W:0.246 / U:0.132 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site