Mercurial > docs > master
comparison ch03.roff @ 16:81f703140554
Wrote about the trash folder.
| author | markus schnalke <meillo@marmaro.de> |
|---|---|
| date | Sun, 22 Apr 2012 13:50:35 +0200 |
| parents | 55ec590cfa07 |
| children | b3c37947764e |
comparison
equal
deleted
inserted
replaced
| 15:66d1835189ad | 16:81f703140554 |
|---|---|
| 116 I value its usefulnes less than the improvement in maintainability, caused | 116 I value its usefulnes less than the improvement in maintainability, caused |
| 117 by the removal. | 117 by the removal. |
| 118 | 118 |
| 119 | 119 |
| 120 .H1 "Draft and Trash Folders | 120 .H1 "Draft and Trash Folders |
| 121 .U2 "The Draft Folder | 121 .U2 "Draft Folder |
| 122 .P | 122 .P |
| 123 Historically, MH provided exactly one draft message, named `\fLdraft\fP' and | 123 Historically, MH provided exactly one draft message, named `\fLdraft\fP' and |
| 124 being located in the MH directory. When starting to compose another message | 124 being located in the MH directory. When starting to compose another message |
| 125 before the former one was sent, the user had been questioned wether to use, | 125 before the former one was sent, the user had been questioned wether to use, |
| 126 refile or replace the old draft. Working on multiple drafts at the same time | 126 refile or replace the old draft. Working on multiple drafts at the same time |
| 173 name. | 173 name. |
| 174 .P | 174 .P |
| 175 All theses changes converted special cases to regular cases, thus | 175 All theses changes converted special cases to regular cases, thus |
| 176 simplifying the tools and increasing the flexibility. | 176 simplifying the tools and increasing the flexibility. |
| 177 | 177 |
| 178 .U2 "Trash Folder | |
| 179 .P | |
| 180 Similar to the situation for drafts is the situation for removed messages. | |
| 181 Historically, a message was deleted by renaming. A specific | |
| 182 \fIbackup prefix\fP, often comma (\fL,\fP) or hash (\fL#\fP), | |
| 183 being prepended to the file name. Thus, MH wouldn't recognize the file | |
| 184 as a message anymore, as only files whose name consists of digits only | |
| 185 are treated as messages. The removed messages remained as files in the | |
| 186 same directory and needed some maintenance job to truly delete them after | |
| 187 some grace time. Usually, by running a command similar to | |
| 188 .DS | |
| 189 find /home/user/Mail \-ctime +7 \-name ',*' | xargs rm | |
| 190 .DE | |
| 191 in a cron job. Within the grace time interval | |
| 192 the original message could be restored by stripping the | |
| 193 the backup prefix from the file name. If however, the last message of | |
| 194 a folder is been removed \(en say message `\fL6\fP' becomes file | |
| 195 `\fL,6\fP' \(en and a new message enters the same folder, thus the same | |
| 196 numbered being given again \(en in out case `\fL6\fP' \(en, if that one | |
| 197 is removed too, then the backup of the former message gets over written. | |
| 198 Thus, the ability to restore removed messages does not only depend on | |
| 199 the ``sweeping cron job'' but also on the removing of further messages. | |
| 200 This is undesireable, because the real mechanism is hidden from the user | |
| 201 and the concequences of further removals are not always obvious. | |
| 202 Further more, the backup files are scattered within the whole mail | |
| 203 storage, instead of being collected at one place. | |
| 204 .P | |
| 205 To improve the situation, the profile entry \fIrmmproc\fP | |
| 206 (previously named \fIDelete-Prog\fP) was introduced, very early. | |
| 207 It could be set to any command, which would care for the mail removal | |
| 208 instead of taking the default action, described above. | |
| 209 Refiling the to-be-removed files to some wastebin folder was a common | |
| 210 example. Nmh's man page for \fLrmm(1)\fP proposes `\fLrefile +d\fP' | |
| 211 (implemented through a shell alias) and `\fLrm `mhpath +d all`\fP' | |
| 212 the empty the wastebin. | |
| 213 Managing the message removal this way is a sane approach. It keeps | |
| 214 the removed messages in one place, makes it easy to remove the backup | |
| 215 files, and, most important, enables the user to use the tools of MH | |
| 216 itself to operate on the removed messages. One can \fLscan\fP them, | |
| 217 \fLshow\fP them, and restore them with \fLrefile(1)\fP. There's no more | |
| 218 need to use \fLmhpath\fP to switch over from MH tools to Unix tools | |
| 219 \(en MH can do it all itself. | |
| 220 .P | |
| 221 This apporach is matches perfect with the concepts of MH, thus making | |
| 222 it powerful. Hence, I made it the default. And even more, I also | |
| 223 removed the old backup prefix approach, as it is clearly less powerful. | |
| 224 Keeping unused alternative in the code is a bad choice as they likely | |
| 225 gather bugs, by not being constantly tested. Also, the increased code | |
| 226 size and more conditions crease the maintenance costs. By strictly | |
| 227 converting to the trash folder approach, I simplified the code base. | |
| 228 \fLrmm(1)\fP calls \fLrefile(1)\fP internally to move the to-be-removed | |
| 229 message to the trash folder (`\fL+trash\fP' by default). Messages | |
| 230 there can be operated on like on any other message in the storage. | |
| 231 The sweep clean, one can use `\fLrmm \-unlink +trash a\fP', where | |
| 232 the `\fL\-unlink\fP' switch causes the files to be truly unliked instead | |
| 233 of moved to the trash folder. | |
| 234 | |
| 178 | 235 |
| 179 .H1 "Paths to ... | 236 .H1 "Paths to ... |
| 180 .P | 237 .P |
| 181 foo | 238 foo |
| 182 | 239 |