Andreas Aardal Hanssen wrote:
I'm sad to say that this patch is not safe and should not be applied yet.
no, please don't be sad. i have never assumeed that i am always writing code without any problem :-)
if i were a specialist of imap, maildir and c++, i might be upset. but i am not :-)
There is a problem with guaranteeing message name uniqueness and that may cause messages to disappear.
can i ask you why the patched code would not guarantee it? it looks generating unique filename to me... when link() worked with no problem, what could be wrong?
Storing messages in cur/ directly has been discussed quite a few times before on the list, and it is provably not safe.
i see... is there any site that has the discussion archive? btw, any official comment by djb so far?
Storing messages with flags in new/ is a new concept, but it suffers from the exact same problem - since the message name under new/ is no longer guaranteed to be unique, the message may be lost.
my understanding is that storing messages with flags in new/ is clearly prohibited by the spec. because it says:
A unique name can be anything that doesn't contain a colon (or slash) and doesn't start with a dot. Do not try to extract information from unique names.
in short, we cannot name messages using `:' which the flags need to have.
The only safe approach to COPY/APPEND with flags is to store the messages in new/ with no flags, then move the messages to cur/ with flags after one whole second has passed. I'm looking into this solution now.
i think that this must be the proper way, too.
having said that, i don't know why and how the patch goes wrong, if original code works fine.
the maildir spec says: When you move a file from new to cur, you have to change its name from uniq to uniq:info.
if the original code is copying a file to `new/uniq', why new code cannot do it as `cur/uniq:info', instead?
in other words, if maildir+"/new/"+fileid+"."+getpid()+"."+hostname is guaranteed to be unique, how can maildir+"/cur/"+fileid+"."+getpid()+"."+hostname+newinfo not be guaranteed?
or am i misunderstanding essentially?
-- Hiroshima
