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 [email protected] https://lists.nongnu.org/mailman/listinfo/nmh-workers
