Carlos E. R. wrote:
Though I challenge you to give me one real life example where one user/program is reading a mail and another one is deleting the same mail without it being a misconfiguration. (^-^)
It wasn't my claim, but his :-)
However, I do just that, though I have to be careful not to open the same folder on two programs. I read most of my email with Alpine, but I have to read, lets say business mails, that come in html, with Thunderbird, so I can end with both clients opened - although I usually close one.
No problem. Just keep in mind that we are talking about reading the same mail in one client when you decide to delete it in the other. (^-^) The worst that will happen is that your first client tells you that you try to open a non-existant file and a refresh of the directory takes care of that.
Another example: I fetch mail from remote servers, like gmail, via imap (fetchmail). This happens in the background. At the same time, I may open the browser to get into gmail and clear the spam. While I'm there, fetchmail may trigger and do a download - and it works fine. However, gmail does not actually delete email.
I don't think this is a valid case since Gmail uses imap and thus it isn't local storage.
Especially the issue of concurrency is exactly why maildir is superior to mbox. Try to have ten applications submit mails to the mailbox at the same time. With mbox you will have to serialize it and lock/unlock the mbox files. It has a severe performance drop and is known to cause lots of problems when separate applications are supposed to access mails from the mbox file.
That's understandable.
Again, this is probably a rather farfetched case when we are talking about local mailbox files.
The solution would be an "engine" like a database that would receive and process read and write process to the mail storage. I suppose that if you have an imap local delivery it does something of the kind. The wu-imap server I think uses mbox for storage, I think; I wonder how it behaves under a big load.
Terrible, especially if we are talking about really big files. Lotus Domino uses single files for mail storage too, but the files are more like databases, but still IO requirements are heavy.
Another problem that often occured was mbox files on nfs storage. The locking was often problematic.
No wonder, nfs and locking is problematic. In fact, IMO, the entire locking issue in Linux is problematic, because there have been several different locking methods: voluntary locking flag files (which name has to be specified), kernel mandatory lock, whatever.
In the procmail man page there are references about how to achieve that locking - if the locking mechanism were well defined since ages, this would be clear cut and a non-issue.
I remember reading in the msdos programmer's manual the locking methods available. You could lock an entire file, a region, for read, for write, in several combinations. When I cam to Linux and read that procmail page, I was... quite surprised.
Yep, and to imagine that every app that is accessing the mail files has to support and agree on the same locking mechanism...
By the way, does anyone know if the problematic setup with the 2 GB mbox files was a 64bit system? I wonder if it was a 32bit limitation of the program and if it could be avoided on a 64 bit system.
Good question.
It maybe that the functions to access a text file position is a longint, which is 2GiB in 32 bits. I know that is the situation in dos/win (for fat files at least); I do not know about Linux. But if the same function calls use 64 bit sized variables, automatically the 2GiB limit would be broken.
Did I mention the "mix" format for mail storage here? It's neither one file per message nor one for all. Googling for it I found some references that wu-imap might be using it. And also I found confirmation about the 2GiB limit:
Hmm... I read the bugreport but haven't heard of this "mix format" before. Is that an application specific format or is there an rfc where the format is explained? Which clients support this mix format? -- Sandy List replies only please! Please address PMs to: news-reply2 (@) japantest (.) homelinux (.) com -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org