Trying to keep everything in sync in the face of errors, without transactions, would require some horribly complicated code.You'd work with a temporary directory and atomically rename it to mail/inbox/42.
Hmm ... that might be more data copying than I would like, especially over a network mount, but yes, I guess it would work.
Do you code the MH tools to look for those cases (more complexity), or leave it for the user to notice something is amiss and give them a command to force a rebuild of all sub-files from the master raw file.You have an fsck-like that can report inconsistencies, this is simply the unpack followed by a diff, and would likely be the same command that refreshes. Just as now, if the user edits mail/inbox/42 then he's expected to know how to miss shooting his foot. This is Unix.
No, it's not that simple. If you edit the message file in the current store, by definition the change is in sync with itself – there's nothing to get out of sync with. But in the exploded directory view, there is. And you can define all you want, but at the end of the day you have to state if you guarantee a consistent internal view across all the files, or not. And if you do, you have to write the code to ensure that consistency. Having two different views on the same message produce different results is a non-starter. It simply can NOT happen.
However, there is a precedent in Mat Blaze's Cryptographic File System(CFS)[1].It's an idea, though every user would need a mount to match their ~/mail. And then I have other folders outside of there referenced with +/some/path that would need more mounts.
Just as with native Plan9 upasfs, you would have to run multiple instances. That's not a problem in practice. On my Plan9 machines I regularly have a half dozen upasfs instances in play. In the UNIX case it would be even simpler, since a single 'nmhfs' instance would serve the entire folder tree. On Plan9 I have to start a separate upasfs instance for each 'folder'.
And I hope it wouldn't slow the already slow pick(1) much.
The exploded view would likely speed up pick in many common cases. One of the things the fileserver does is create a dynamic cache of the metadata for messages in the folder. By caching commonly-used header content (From, To, CC, Subject, Date), many common pick operations wouldn't need to directly touch any of the message files. BTW, it's that simple metadata cache (on top of the MH-style on disk layout) that makes the CMU Cyrus IMAP server so blindingly fast. --lyndon
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Nmh-workers mailing list Nmh-workers(_at_)nongnu(_dot_)org https://lists.nongnu.org/mailman/listinfo/nmh-workers