Hi > > Saying that, I don't see a reason not to make this work for people who > are > > prepared to accept the risk or who know for sure they are delivering mail > > sequentially. With fdm, you will want to set queue-high/queue-low to 1, > and > > perhaps parallel-accounts to 1 if you have multiple accounts delivering > to > > the > > same maildir. > > You mean because of locks in the file system code with rename ?
I meant there is a possibility of having races between fdm delivery children (it forks a separate one for each child), although I had another look and since the filename contains the PID that is more unlikely than I first thought - most platforms don't reuse PIDs that quickly. It is still unpredictable so do note that if >1 process is accessing the maildir at a time, you could lose mail, even if it is an outside chance. > I had not thought of. > > But, the read on a maildir -with a big amount of mails- stays faster, > isn't it ? (Actually, I am new to fdm/maildir/mboxes/mutt... I used > Evolution > and webmails...) It depends how it is implemented but there is no reason mbox reads or appends should be slower than maildir; a full mailbox scan will be slower and deletion will be much slower. The biggest problems with mboxes is that only one process can access them simultaneously and some big operations (like delete) can require a copy and rewrite of the entire file to do safely. I really don't like mboxes, I just wanted to note that they do have locking so you will not lose mail due to this limitation in AFS. That doesn't excuse their other problems though. Thinking about it again if I was you I would probably use maildirs anyway (once fdm is changed to work around the problem) but you should try to be careful that as much as possible only one program writes to the maildir at a time. > > This diff is reasonable, but if possible I'd rather it was implemented as > a > > wrapper function (xlink?) which has the same semantics as link but falls > > back > > to stat/rename if it fails with EXDEV. > > Okay, I will try to study it, tomorrow. Great! Thanks Nicholas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
