docs/master

diff discussion.roff @ 108:dd5620bf8659

Wrote about storing attachments.
author markus schnalke <meillo@marmaro.de>
date Sat, 23 Jun 2012 23:53:52 +0200
parents 9f672d3a25f9
children 2b094b8fb422
line diff
     1.1 --- a/discussion.roff	Sat Jun 23 22:12:14 2012 +0200
     1.2 +++ b/discussion.roff	Sat Jun 23 23:53:52 2012 +0200
     1.3 @@ -2116,7 +2116,109 @@
     1.4  
     1.5  .U3 "Storing Attachments
     1.6  .P
     1.7 -FIXME
     1.8 +Extracting MIME parts of a message and storing them to disk is done by
     1.9 +.Pn mhstore .
    1.10 +The program has two operation modes,
    1.11 +.Sw -auto
    1.12 +and
    1.13 +.Sw -noauto .
    1.14 +With the former one, each part is stored under the filename given in the
    1.15 +MIME part's meta information, if available.
    1.16 +This naming information is usually available for modern attachments.
    1.17 +If no filename is available, this MIME part is stored as if
    1.18 +.Sw -noauto
    1.19 +would have been specified.
    1.20 +In the
    1.21 +.Sw -noauto
    1.22 +mode, the parts are processed according to rules, defined by
    1.23 +.Pe mhstore-store-*
    1.24 +profile entries.
    1.25 +These rules define generic filename templates for storing
    1.26 +or commands to post-process the contents in arbitrary ways.
    1.27 +If no matching rule is available the part is stored under a generic
    1.28 +filename, built from message number, MIME part number, and MIME type.
    1.29 +.P
    1.30 +The
    1.31 +.Sw -noauto
    1.32 +mode had been the default in nmh because it was considered safe,
    1.33 +in contrast to the
    1.34 +.Sw -auto
    1.35 +mode.
    1.36 +In mmh,
    1.37 +.Sw -auto
    1.38 +is not dangerous anymore.
    1.39 +Two changes were necessary:
    1.40 +.BU
    1.41 +Any directory path is removed from the proposed filename.
    1.42 +Thus, the files are always stored in the expected directory.
    1.43 +.Ci 41b6eadbcecf63c9a66aa5e582011987494abefb
    1.44 +.BU
    1.45 +Tar files are not extracted automatically any more.
    1.46 +Thus, the rest of the file system will not be touched.
    1.47 +.Ci 94c80042eae3383c812d9552089953f9846b1bb6
    1.48 +.LP
    1.49 +Now, the outcome of mmh's
    1.50 +.Cl "mhstore -auto
    1.51 +can be forseen from the output of
    1.52 +.Cl "mhlist -verbose" .
    1.53 +.P
    1.54 +The
    1.55 +.Sw -noauto
    1.56 +mode is seen to be more powerful but less convenient.
    1.57 +On the other hand,
    1.58 +.Sw -auto
    1.59 +is safe now and
    1.60 +storing attachments under their original name is intuitive.
    1.61 +Hence,
    1.62 +.Sw -auto
    1.63 +serves better as the default option.
    1.64 +.Ci 3410b680416c49a7617491af38bc1929855a331d
    1.65 +.P
    1.66 +Files are stored into the directory given by the
    1.67 +.Pe Nmh-Storage
    1.68 +profile entry, if set, or
    1.69 +into the current working directory, otherwise.
    1.70 +Storing to different directories is only possible with
    1.71 +.Pe mhstore-store-*
    1.72 +profile entries.
    1.73 +.P
    1.74 +Still, in both modes, existing files get overwritten silently.
    1.75 +This can be considered a bug.
    1.76 +Yet, each other behavior has its draw-backs, too.
    1.77 +Refusing to replace files requires adding a
    1.78 +.Sw -force
    1.79 +option.
    1.80 +Users will likely need to invoke
    1.81 +.Pn mhstore
    1.82 +a second time with
    1.83 +.Sw -force
    1.84 +then.
    1.85 +Eventually, only the user can decide in the concrete case.
    1.86 +This requires interaction, which I like to avoid if possible.
    1.87 +Appending a unique suffix to the filename is another bad option.
    1.88 +For now, the behavior remains as it is.
    1.89 +.P
    1.90 +In mmh, only MIME parts of type message are special in
    1.91 +.Pn mhstore 's
    1.92 +.Sw -auto
    1.93 +mode.
    1.94 +Instead of storing message/rfc822 parts as files to disk,
    1.95 +they are stored as messages into the current mail folder.
    1.96 +The same applies to message/partial, only, the parts are reassembled
    1.97 +automatically before.
    1.98 +Parts of type message/external-body are not automatically retrieved
    1.99 +anymore. Instead, Information on how to retrieve them is output.
   1.100 +Not supporting this rare case saved nearly one thousand lines of code.
   1.101 +.Ci 55e1d8c654ee0f7c45b9361ce34617983b454c32
   1.102 +.\" XXX mention somewhere else too: (The profile entry `nmh-access-ftp'
   1.103 +.\"     and sbr/ruserpass.c for reading ~/.netrc are gone now.)
   1.104 +Not special anymore is `application/octet-stream; type=tar'.
   1.105 +Automatically extracting such MIME parts had been the dangerous part
   1.106 +of the
   1.107 +.Sw -auto
   1.108 +mode.
   1.109 +.Ci 94c80042eae3383c812d9552089953f9846b1bb6
   1.110 +
   1.111  
   1.112  
   1.113  .U3 "Showing MIME Messages