Hi Lyndon,
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.
you still face the problem of non-MH commands directly modifying
sub-components of the messages. What happens when the raw,
part1-encoded, and part1-decoded files all differ on their idea of the
contents of that first MIME part?
You define what happens. Some of the representations would have
read-only file permissions. You'd state what was the master
representations. I expect there would be a means to refresh some of the
representations, from the masters by default.
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.
However, there is a precedent in Mat Blaze's Cryptographic File System
(CFS)[1]. Faced with a similar problem (exporting a decrypted view of
an encrypted directory tree), his code presented itself as an NFS
fileserver from which the user could mount the decrypted view of the
directory tree.
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. And I hope it wouldn't slow
the already slow pick(1) much.
Cheers, Ralph.
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers