# HG changeset patch
# User markus schnalke <meillo@marmaro.de>
# Date 1340488432 -7200
# Node ID dd5620bf8659e8a47a73eb6dff4419408351ef51
# Parent  9f672d3a25f96c1fd5d7db64f3abe4a6441bbbe2
Wrote about storing attachments.

diff -r 9f672d3a25f9 -r dd5620bf8659 discussion.roff
--- a/discussion.roff	Sat Jun 23 22:12:14 2012 +0200
+++ b/discussion.roff	Sat Jun 23 23:53:52 2012 +0200
@@ -2116,7 +2116,109 @@
 
 .U3 "Storing Attachments
 .P
-FIXME
+Extracting MIME parts of a message and storing them to disk is done by
+.Pn mhstore .
+The program has two operation modes,
+.Sw -auto
+and
+.Sw -noauto .
+With the former one, each part is stored under the filename given in the
+MIME part's meta information, if available.
+This naming information is usually available for modern attachments.
+If no filename is available, this MIME part is stored as if
+.Sw -noauto
+would have been specified.
+In the
+.Sw -noauto
+mode, the parts are processed according to rules, defined by
+.Pe mhstore-store-*
+profile entries.
+These rules define generic filename templates for storing
+or commands to post-process the contents in arbitrary ways.
+If no matching rule is available the part is stored under a generic
+filename, built from message number, MIME part number, and MIME type.
+.P
+The
+.Sw -noauto
+mode had been the default in nmh because it was considered safe,
+in contrast to the
+.Sw -auto
+mode.
+In mmh,
+.Sw -auto
+is not dangerous anymore.
+Two changes were necessary:
+.BU
+Any directory path is removed from the proposed filename.
+Thus, the files are always stored in the expected directory.
+.Ci 41b6eadbcecf63c9a66aa5e582011987494abefb
+.BU
+Tar files are not extracted automatically any more.
+Thus, the rest of the file system will not be touched.
+.Ci 94c80042eae3383c812d9552089953f9846b1bb6
+.LP
+Now, the outcome of mmh's
+.Cl "mhstore -auto
+can be forseen from the output of
+.Cl "mhlist -verbose" .
+.P
+The
+.Sw -noauto
+mode is seen to be more powerful but less convenient.
+On the other hand,
+.Sw -auto
+is safe now and
+storing attachments under their original name is intuitive.
+Hence,
+.Sw -auto
+serves better as the default option.
+.Ci 3410b680416c49a7617491af38bc1929855a331d
+.P
+Files are stored into the directory given by the
+.Pe Nmh-Storage
+profile entry, if set, or
+into the current working directory, otherwise.
+Storing to different directories is only possible with
+.Pe mhstore-store-*
+profile entries.
+.P
+Still, in both modes, existing files get overwritten silently.
+This can be considered a bug.
+Yet, each other behavior has its draw-backs, too.
+Refusing to replace files requires adding a
+.Sw -force
+option.
+Users will likely need to invoke
+.Pn mhstore
+a second time with
+.Sw -force
+then.
+Eventually, only the user can decide in the concrete case.
+This requires interaction, which I like to avoid if possible.
+Appending a unique suffix to the filename is another bad option.
+For now, the behavior remains as it is.
+.P
+In mmh, only MIME parts of type message are special in
+.Pn mhstore 's
+.Sw -auto
+mode.
+Instead of storing message/rfc822 parts as files to disk,
+they are stored as messages into the current mail folder.
+The same applies to message/partial, only, the parts are reassembled
+automatically before.
+Parts of type message/external-body are not automatically retrieved
+anymore. Instead, Information on how to retrieve them is output.
+Not supporting this rare case saved nearly one thousand lines of code.
+.Ci 55e1d8c654ee0f7c45b9361ce34617983b454c32
+.\" XXX mention somewhere else too: (The profile entry `nmh-access-ftp'
+.\"     and sbr/ruserpass.c for reading ~/.netrc are gone now.)
+Not special anymore is `application/octet-stream; type=tar'.
+Automatically extracting such MIME parts had been the dangerous part
+of the
+.Sw -auto
+mode.
+.Ci 94c80042eae3383c812d9552089953f9846b1bb6
+
 
 
 .U3 "Showing MIME Messages