On Nov 11, 2014, at 4:13 AM, Ralph Corderoy <ralph(_at_)inputplus(_dot_)co(_dot_)uk> wrote:
You state impossibility. Could you explain why it's impossible? We may not want all of the redundancy upasfs provides, but a new message store that duplicates some of the information, e.g. providing raw as-received email and separate decoded, one-per-line, headers file, seems possible.
I meant impossible in any practical sense on a POSIX system. Guaranteeing atomicity of the state of the exploded message layout on disk pretty much requires a transactional filesystem with full commit/rollback semantics. Trying to keep everything in sync in the face of errors, without transactions, would require some horribly complicated code. I can't see how the benefits could possibly justify added complexity. But beyond that, even with transactional semantics, 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? Do you consider the original raw file the master view? How do tell when the files get out of sync? With anno(1)'s ability to modify headers, you can't necessarily rely on timestamps. Do the sub-files reference the encapsulating portion of the master file? If yes, what's the trigger? You could keep side-hashes of each of the MIME parts in each of the files, updated whenever an MH command writes to a data file, then compare the mtimes of the data file and its hash. But things can (and will) get out of sync, eventually. 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. The reason upasfs gets away with this is because it is exporting an alternative view of the single underlying mbox file.
Having upasfs itself, or something like it, would require a dependency on 9P though? Is that now standard on nmh's platforms?
I doubt you'll convince the Open Group of the merits of 9P :-P 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. A native UNIX implementation of a upasfs-like service could do the same thing. --lyndon [1] http://www.academia.edu/8690714/A_cryptographic_file_system_for_UNIX
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