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