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

[Ralph Corderoy]

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.