# HG changeset patch # User markus schnalke # Date 1335095435 -7200 # Node ID 81f703140554c6ebef35ef2d916c2df5b5c4e0f7 # Parent 66d1835189ade4718ec9b404187c3d9499d7d5aa Wrote about the trash folder. diff -r 66d1835189ad -r 81f703140554 ch03.roff --- a/ch03.roff Sun Apr 22 12:34:14 2012 +0200 +++ b/ch03.roff Sun Apr 22 13:50:35 2012 +0200 @@ -118,7 +118,7 @@ .H1 "Draft and Trash Folders -.U2 "The Draft Folder +.U2 "Draft Folder .P Historically, MH provided exactly one draft message, named `\fLdraft\fP' and being located in the MH directory. When starting to compose another message @@ -175,6 +175,63 @@ All theses changes converted special cases to regular cases, thus simplifying the tools and increasing the flexibility. +.U2 "Trash Folder +.P +Similar to the situation for drafts is the situation for removed messages. +Historically, a message was deleted by renaming. A specific +\fIbackup prefix\fP, often comma (\fL,\fP) or hash (\fL#\fP), +being prepended to the file name. Thus, MH wouldn't recognize the file +as a message anymore, as only files whose name consists of digits only +are treated as messages. The removed messages remained as files in the +same directory and needed some maintenance job to truly delete them after +some grace time. Usually, by running a command similar to +.DS +find /home/user/Mail \-ctime +7 \-name ',*' | xargs rm +.DE +in a cron job. Within the grace time interval +the original message could be restored by stripping the +the backup prefix from the file name. If however, the last message of +a folder is been removed \(en say message `\fL6\fP' becomes file +`\fL,6\fP' \(en and a new message enters the same folder, thus the same +numbered being given again \(en in out case `\fL6\fP' \(en, if that one +is removed too, then the backup of the former message gets over written. +Thus, the ability to restore removed messages does not only depend on +the ``sweeping cron job'' but also on the removing of further messages. +This is undesireable, because the real mechanism is hidden from the user +and the concequences of further removals are not always obvious. +Further more, the backup files are scattered within the whole mail +storage, instead of being collected at one place. +.P +To improve the situation, the profile entry \fIrmmproc\fP +(previously named \fIDelete-Prog\fP) was introduced, very early. +It could be set to any command, which would care for the mail removal +instead of taking the default action, described above. +Refiling the to-be-removed files to some wastebin folder was a common +example. Nmh's man page for \fLrmm(1)\fP proposes `\fLrefile +d\fP' +(implemented through a shell alias) and `\fLrm `mhpath +d all`\fP' +the empty the wastebin. +Managing the message removal this way is a sane approach. It keeps +the removed messages in one place, makes it easy to remove the backup +files, and, most important, enables the user to use the tools of MH +itself to operate on the removed messages. One can \fLscan\fP them, +\fLshow\fP them, and restore them with \fLrefile(1)\fP. There's no more +need to use \fLmhpath\fP to switch over from MH tools to Unix tools +\(en MH can do it all itself. +.P +This apporach is matches perfect with the concepts of MH, thus making +it powerful. Hence, I made it the default. And even more, I also +removed the old backup prefix approach, as it is clearly less powerful. +Keeping unused alternative in the code is a bad choice as they likely +gather bugs, by not being constantly tested. Also, the increased code +size and more conditions crease the maintenance costs. By strictly +converting to the trash folder approach, I simplified the code base. +\fLrmm(1)\fP calls \fLrefile(1)\fP internally to move the to-be-removed +message to the trash folder (`\fL+trash\fP' by default). Messages +there can be operated on like on any other message in the storage. +The sweep clean, one can use `\fLrmm \-unlink +trash a\fP', where +the `\fL\-unlink\fP' switch causes the files to be truly unliked instead +of moved to the trash folder. + .H1 "Paths to ... .P