[anthk]

Yes, over NFS it's slow, but nowadays everyone has local devices or they just login via SSH or virtualize whole desktops.

Still, if you have over 100k emails, mbox will be slow to parse for obvious reasons as it has to parse every line with often having mboxes as huge as 500MB if not more. Your FS and VFS layers will do a far better task on reading the first lines of thousands of files. In such case your mail client will parse the headers to generate the inbox layout in a much faster way.

[jcranmer]

> Still, if you have over 100k emails, mbox will be slow to parse for obvious reasons as it has to parse every line with often having mboxes as huge as 500MB if not more.

No, you don't. You store in your metadata database what the offset of the message in the mbox file is. If you don't have such a metadata database, then you're going to be very slow no matter what the storage is.

[anthk]

Load a GB sized mbox into mail(1) and then say that again.

Mbox it's just a literal

cat mail/*.msgs >> mbox

setup.

Reading will be slow, and file locking will be hell.

Unix should've switched to maildir long ago. Since 1999 storage and inodes are not a problem any more.

[jcranmer]

> Load a GB sized mbox into mail(1) and then say that again.

In other words, use mbox with an application that doesn't have its own message metadata database and you get problems. But if you're designing your own email client in the 21st century, then you're going to want to build your own message metadata database.

[15457345234]

This thread is very strange with people talking about mail formats and methods of handling email that haven't seen serious use since 1990

I mean, I studied Comp Sci at university in 1997 and we were given IMAP credentials

[eru]

I used maildir with mutt in the 2010s.

[15457345234]

You and 100 other people globally