# HG changeset patch # User markus schnalke # Date 1341263659 -7200 # Node ID 0b9aa74ced4dfc11464c447848093e9403f0c7a7 # Parent 01af3c0dfe7b86e1110cea2b93656ef27ecb4bf1 Reworked the text on the Trash Folder. diff -r 01af3c0dfe7b -r 0b9aa74ced4d discussion.roff --- a/discussion.roff Mon Jul 02 17:59:21 2012 +0200 +++ b/discussion.roff Mon Jul 02 23:14:19 2012 +0200 @@ -3477,114 +3477,162 @@ .H2 "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 (\c -.Fn , ) -or hash (\c -.Fn # ), -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 +Historically, a message was ``deleted'' by prepending a specific +\fIbackup prefix\fP, usually the comma character, +to the file name. +The specific message would vanish from MH because only files with +non-digit characters in their name are not treated as messages. +Although files remained in the file system, +the messages were no more visible in MH. +To truly delete them, a maintenance job is needed. +Usually a cron job is installed to delete them after a grace time. +For instance: .VS -find /home/user/Mail -ctime +7 -name ',*' | xargs rm +find $HOME/Mail -type f -name ',*' -ctime +7 -delete VE -in a cron job. -Within the grace time interval -the original message could be restored by stripping the +In such a setup, the original message can be restored +within the grace time interval by stripping the the backup prefix from the file name. -If however, the last message of -a folder is been removed \(en say message +But one can not rely on this statement. +If the last message of a folder with six messages (1-6) is removed, +message +.Fn 6 , +becomes file +.Fn ,6 . +If then a new message enters the same folder, it will be given +the number one higher than the highest existing message. +In this case the message is named .Fn 6 -becomes file -.Fn ,6 -\(en and a new message enters the same folder, thus the same -numbered being given again \(en in our case -.Fn 6 -\(en, if that one -is removed too, then the backup of the former message gets overwritten. -Thus, the ability to restore removed messages does not only depend on +then. +If this message is removed as well, +then the backup of the former message gets overwritten. +Hence, 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 undesirable, because the real mechanism is hidden from the user -and the consequences 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. +It is undesirable to have such obscure and complex mechanisms. +The user should be given a small set of clear assertions. +``Removed files are restorable within a seven-day grace time.'' +is such a clear assertion. +With the addition ``... unless a message with the same name in the +same folder is removed before.'' the statement becomes complex. +A user will hardly be able to keep track of any removal to know +if the assertion still holds true for a specific file. +The the real mechanism is practically obscure to the user. +The consequences of further removals are not obvious. .P -To improve the situation, the profile entry +Further more, the backup files are scattered within the whole mail storage. +This complicates managing them. +It is possible, with help of +.Pn find , +but everything would be more convenient +if the deleted messages would be collected in one place. +.P +The profile entry .Pe rmmproc (previously named .Pe Delete-Prog ) -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 garbage folder was a common -example. +was introduced very early to improve the situation. +It could be set to any command, which would be executed to removed +the specified messages. +This would override the default action, described above. +Refiling the to-be-removed files to a garbage folder is the usual example. Nmh's man page -.Mp rmm(1) -proposes +.Mp rmm (1) +proposes to set the +.Pe rmmproc +to .Cl "refile +d -to move messages to the garbage folder and +to move messages to the garbage folder, +.Fn +d , +instead of renaming them with the backup prefix. +The man page proposes additionally the expunge command .Cl "rm `mhpath +d all` -the empty the garbage folder. -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 -.Pn scan -them, -.Pn show -them, and restore them with +to empty the garbage folder. +.P +Removing messages in such a way has advantages. +The mail storage is prevented from being cluttered with removed messages +because they are all collected in one place. +Existing and removed messages are thus separated more strictly. +No backup files are silently overwritten. +Most important is the ability to keep removed messages in the MH domain. +Messages in the trash folder can be listed like those in any other folder. +Deleted messages can be displayed like any other messages. +Restoring a deleted messages can be done with .Pn refile . -There's no more -need to use -.Pn mhpath -to switch over from MH tools to Unix tools \(en MH can do it all itself. +All operations on deleted files are still covered by the MH tools. +The trash folder is just like any other folder in the mail storage. .P -This approach 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. +Similar to the draft folder case, I dropped the old backup prefix approach +in favor for replacing it by the better suiting trash folder system. +Hence, +.Pn rmm +calls +.Pn refile +to move the to-be-removed message to the trash folder, +.Fn +trash +by default. +To sweep it clean, one can use +.Cl "rmm -unlink +trash a" , +where the +.Sw -unlink +switch causes the files to be unlinked. +.P +Dropping the legacy approach and completely converting to the new approach +simplified the code base. +The relationship between +.Pn rmm +and +.Pn refile +was inverted. +In mmh, +.Pn rmm +invokes +.Pn refile , +which used to be the other way round. +Yet, the relationship is simpler now. +No more can loops, like described in nmh's man page for +.Mp refile (1), +occur: +.QS +Since +.Pn refile +uses your +.Pe rmmproc +to delete the message, the +.Pe rmmproc +must NOT call +.Pn refile +without specifying +.Sw -normmproc +or you will create an infinite loop. +.QE +.LP +.Pn rmm +either unlinks a message with +.Fu unlink() +or invokes +.Pn refile +to move it to the trash folder. +.Pn refile +does not invoke any tools. +.P + + + 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. -.Pn rmm -calls -.Pn refile -internally to move the to-be-removed -message to the trash folder (\c -.Fn +trash -by default). -Messages -there can be operated on like on any other message in the storage. -The sweep clean, one can use -.Cl "rmm -unlink +trash a" , -where the -.Sw -unlink -switch causes the files to be truly unliked instead -of moved to the trash folder. + +By generalizing the message removal in a way that it becomes covered +by the MH concepts makes the whole system more powerful. + .H2 "Path Notations .P -foo +FIXME! TODO -.H2 "MIME Integration -.P -user-visible access to whole messages and MIME parts are inherently -different - .H2 "Of One Cast .P