Re: [Nmh-workers] What are and what should be the qualifications for a current nmh user

[Lyndon Nerenberg]

On Nov 11, 2014, at 4:13 AM, Ralph Corderoy <address@hidden> 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