News for hackers. Stuff that matters.
Re:Files Are Hard (2015) by loopz on Sunday December 01, 2019 @08:45AM (#21675449)
The sane old-school way to store mail is using directories and files. Mozilla Thunderbird does this and I've never had a corruption issue. If need be, you can index or open individual files in text editor, as they're all plain text. Would hope for revitalization of the application, but works for my personal use cases.

Yeah, files, are hard.

Re:Files Are Hard (2015) by garaetjjte on Sunday December 01, 2019 @10:25AM (#21675864)
I don't think Thunderbird is good example here..

It stores inboxes in mbox-like format, then some metadata in very weird .msf format, and on top on that SQLite database for search indexing. And it has some bewildering bugs like mixing up titles and content from two different messages, or slapping on messages date pulled from thin air..

Re:Files Are Hard (2015) by cesarb on Sunday December 01, 2019 @10:56AM (#21676013)
> or slapping on messages date pulled from thin air..

IME, this happens when the message doesn't have a date (that is, Date header missing or invalid). There's an open request on bugzilla to use the last Received date in these cases.

Re:Files Are Hard (2015) by q3k on Sunday December 01, 2019 @09:15AM (#21675562)
The Maildir format, however, barely uses any tricky filesystem features. In order, all the semantics you need to support are:

- atomic file create with content

- atomic directory create

- atomic file move

- atomic file delete

- single-level file enumeration

No file modification in place which is the actual hard path. Not even appending to existing files.

Incidentally, reliable databases tend to also not rely on file modification, opting for a log-and-compact strategy instead.

It's when you start modifying existing data that 'just use a filesystem' becomes unviable.

Re:Files Are Hard (2015) by blattimwind on Sunday December 01, 2019 @10:39AM (#21675934)
> - atomic file create with content

No FS guarantees this. You can emulate this by writing to a tmp location, syncing and performing a move.

Re:Files Are Hard (2015) by gizmo686 on Sunday December 01, 2019 @10:48AM (#21675976)
When you use rename to overwrite a file, it guarentees that at any point in time, newpath will refer to either the original file, or the new file. This is atomic enough to give you effectivly atomic file creation with contents.

It is not technically atomic, because there is a period where oldpath and newpath both refer to the same file, but I don't think that is an issue for this usecase.

Re:Files Are Hard (2015) by manwe150 on Sunday December 01, 2019 @03:38PM (#21677656)
Linux has the O_TMPFILE flag to open, for which this is one of the use cases described in the man page. I can’t say about “guaranteed” though. I assume Microsoft Transactional NTFS (TxF) also had (or has) this capability—but deprecated.
Re:Files Are Hard (2015) by blattimwind on Tuesday December 03, 2019 @08:10AM (#21691953)
TxF is a corner stone of Windows Update, I can't really imagine them removing it. I always assumed they marked it deprecated to avoid supporting it towards customers.
Re:Files Are Hard (2015) by Moru on Sunday December 01, 2019 @09:03AM (#21675514)
Yes, just use thunderbird/netscape and be done with it. I still have my old installation running, upgrading and migrating as needed since netscape time. I have mails from 1999 on there still.

At work they were using outlook for mail and wondering why it crashes now and then (past 2 GB it starts writing over the start of the file or some such). We get a lot of big documents on email so switched to thunderbird and all is well since. Had to switch mailserver though since that one also only handled 2 GB. No idea what they were running but most likely something MS-related. Most of their stuff was MS at the time.

Re:Files Are Hard (2015) by Avamander on Sunday December 01, 2019 @10:38AM (#21675933)
I wish there'd be a native e-mail client that utilized a RDBMS properly, I want a really fast full-text search, I want fast filters. The current ones have all been very unsatisfactory, mostly because the file-based approach doesn't allow them to. It really isn't sane in my opinion.
Re:Files Are Hard (2015) by bronson on Sunday December 01, 2019 @11:40AM (#21676245)
Have you tried notmuch? https://notmuchmail.org/

It uses a Xapian index, not an RDBMS, but it's impressive. RDBMSes aren't known for producing good natural language search results.

Re:Files Are Hard (2015) by Avamander on Sunday December 01, 2019 @05:55PM (#21678373)
I have not, I am tempted however, I really dislike the power Google has over me.
Re:Files Are Hard (2015) by ses1984 on Sunday December 01, 2019 @10:43AM (#21675957)
"fast full text search" is something better provided by software that specializes in fast full text search.

Rdbms for the email use case is kind of orthogonal to fast full text search.

Re:Files Are Hard (2015) by Avamander on Sunday December 01, 2019 @10:54AM (#21676008)
A RDBMS can provide a fast full text search alongside other useful features, can you elaborate how it's orthogonal?

Oh, and I also dislike even the idea that I have to find some "specialized software" to have basic functionality in my e-mail client. That's why most still suck a*.

Re:Files Are Hard (2015) by ses1984 on Sunday December 01, 2019 @11:17AM (#21676119)
You probably want something that checks for similarly spelled words, maybe natural language processing, whole or partial word matching, indices on all this, etc.

If all you want is to grep your email, that's different, I think you can accomplish that with pine or other text mode email clients.

Re:Files Are Hard (2015) by jakeogh on Sunday December 01, 2019 @01:45PM (#21677064)
O ya, you want alot:)

links in my stack: https://github.com/jakeogh/gpgmda-client