dovecot - May 2005 - problem with test69

Hi all, I noticed a problem with test69. I can recreate it with the
following steps:

- create a folder
- copy about 200 emails from INBOX to this folder

The copy succeeds, I can see with rawlog that it actually moves the 200 emails
around. I can see on the spool that there are 200 emails. This is maildir,
with spool over NFS.

Now I immediately select the new folder. I now see only a part of the emails
reported. And with rawlog I indeed see something like:

* FLAGS (\Answered \Flagged \Deleted \Seen \Draft Junk)
* OK [PERMANENTFLAGS (\Answered \Flagged \Deleted \Seen \Draft Junk \*)] Flags p
ermitted.
* 158 EXISTS
* 158 RECENT
* OK [UNSEEN 3] First unseen.
* OK [UIDVALIDITY 1115970206] UIDs valid
* OK [UIDNEXT 217] Predicted next UID
2 OK [READ-WRITE] Select completed.

My client faithfully reports 158 instead of 200. 

If I now close/open my client, and re-select, I see 200.

This I can reproduce with several different clients, but its pretty
obvious it isnt a client issue. I also reproduced this with different users. 

Anyone see this also? NFS issue?

Cor

On Fri, 2005-05-13 at 10:00 +0200, Cor Bosman wrote:
> Hi all, I noticed a problem with test69. I can recreate it with the
> following steps:
> 
> - create a folder
> - copy about 200 emails from INBOX to this folder
> 
> The copy succeeds, I can see with rawlog that it actually moves the 200
emails
> around. I can see on the spool that there are 200 emails. This is maildir,
> with spool over NFS.
> 
> Now I immediately select the new folder. I now see only a part of the
emails
> reported. And with rawlog I indeed see something like:
After this, are the missing mails still in new/ directory?
> This I can reproduce with several different clients, but its pretty
> obvious it isnt a client issue. I also reproduced this with different
users.
How about manually:

x select inbox
x create testfold1
x copy 1:200 testfold1
x select testfold1

I couldn't reproduce it like that.
> Anyone see this also? NFS issue?
Yes, almost certainly. Although I thought my code handled this
differently in a way that it would have worked. Guess I'll have to
change it.

The problem is that if you're rename()ing files from new/ to cur/ while
readdir()ing through the new/ dir, with NFS some files are skipped.

So, choices would be to either scan/rename through the dir until it's
empty, or to change the rename() happen only after everything is read to
memory. I'll probably do the latter.