[Dovecot] Maildir unreliability

[Timo Sirainen]

On 25.10.2004, at 23:11, Geo Carncross wrote:

> This is nonsense. The problem is that the behavior of readdir() is
> confusing.
>
> Why should unlink() or rename() invalidate data that your C library
> ALREADY READ from the directory?

Why do you think it was already read? It wasn't. That's the problem. An 
existing renamed file may never be returned by one opendir() .. 
readdir() .. closedir() loop.

> 		if (stat(d->d_name, &sb) == -1)continue;
>
> After your check for the "." in the first character of the d->d_name
> (about line 41) and all will be good. No amount of twiddling with
> USE_UNLINK or FILES is going to affect it.

Right. Because the stat() always fails so the whole thing does nothing. 
If you actually do the correct check:

                 sprintf(path, PATH"/%s", d->d_name);
                 if (stat(path, &sb) < 0)
                         continue;

Then it's just as broken as before, but works more slowly.

> Of course. For readdir() to be atomic, it would need to do a system 
> call
> for each directory entry. This is exactly why readdir() doesn't, so 
> that
> you do one syscall for every (say) 50 entries, and if you want 
> validity,
> you'll do a stat() yourself.

I don't have a problem with readdir() returning a file that doesn't 
exist anymore. I have a problem of readdir() not returning an existing 
file. The exact opposite.

> Now: Maildir quite obviously wasn't designed with IMAP in mind. IMAP 
> has
> some (largely ridiculous) requirements that Maildir simply doesn't make
> easy.

UIDs mostly.

> The largest problem (with Maildir) is this renaming of file identifiers
> and moving things in and out of cur/. It's only necessary so programs
> don't have to open() in order to read flags (after all, they JUST did a
> readdir())...

Out of cur/? open() to read flags? I don't understand.

> Since the names aren't going to change in cur/, you can get away with
> just doing a stat() in there [[ after all, you just rename()'d it into
> cur/ if you're working on new ]]
>
> Unfortunately, cur/ is often bigger than new/.

Are you trying to say that files wouldn't be allowed to be renamed 
inside cur/ to change their flags?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
URL: <http://dovecot.org/pipermail/dovecot/attachments/20041025/b4d3704c/attachment-0001.bin>