From: MERC::"uunet!CRVAX.SRI.COM!RELAY-INFO-VAX" 19-AUG-1992 01:40:05.95 To: info-vax@kl.sri.com CC: Subj: VMS/MAIL - Summary of Replies to DELETE/ALL Query (13-Aug) I would like to thank everyone who responded to my recent query as to why the DELETE/ALL command in VMS MAIL also does away with the folder from which the items are deleted. The replies were prompt, cordial and informative. For the benefit of others, I append a summary of what I learned about the nature of the phenomenon and possible solutions. There is some repetition here, but I included a number of replies so as to incorporate information that appears in one post but not others. First, two corrections to my original message: - the same thing would happen if I deleted the items in the folder one by one; DELETE/ALL just makes it happen faster - I described the loss of the folder as "like chucking out your filing cabinet every time you throw out some old letters!" "No, deleting MAIL.MAI would be like chucking your filing cabinet. Deleting an empty folder is like pulling a manila file folder out of the cabinet and tossing it in the trash can. What you are suggesting is like pulling a manila file folder out of the cabinet, removing the papers inside it, and throwing them in the trash, and then putting the empty manila folder back into the drawer." (Bob Marshall) I. Why does the problem occur? "To understand this you have to understand how MAIL stores messages. The core is the indexed sequential file MAIL.MAI. This file has records for each message and each record has two keys. The primary key is based on the timestamp of when the message was received. The second, alternate key is the name of the folder in which the message has been filed. This alternate key is the only place where VMS keeps track of which folders exist so a folder cannot exist without a message in it. This has the benefit of simplicity as the file only contains one type of record. It is also why messages in a folder are always sorted by date. When MAIL reads the file by the alternate key it gets the records in primary key order." (Bruce Hudson) "I think most of the behavior you're seeing is due to the structure of the VMSMAIL datafile you have in your directory. Folders are merely a construct of the file structure in that they are RMS secondary keys into this ISAM file. When you re-file stuff in another folder, MAIL takes all records in the file with that secondary key and changes the key to a new folder name. So, when you delete all memos in a specific folder, you're really deleting all records which contain this secondary key. With no records present, the folder no longer exists." (Michael Vilain) "In the current VMSmail implementation, a folder name has no separate existance outside of just being a particular value of a key field in one or more VMSmail records. Doing a directory of a particular folder is done by just looking up all the records with a that value in the folder name field (in the order of the other key, the record creation date/time). Deleting all the messages in a folder is done by deleting all the records in the mail file with some particular value in the folder name field (and the associated message files). So there is no way to get the behavior you want without re-designing the mail file format, something that's not likely to happen soon if at all" (James Harvey) "In order to understand this phenomenon, you have to know a little bit about how mail messages are stored in the MAIL.MAI file: The header of each message (From, To, Subject, date/time, some flags and other information) occupies a single record in the MAIL.MAI file. The mail file is an indexed file (i.e. each record has one or more "keys" on which retrieval may be based). This is done to avoid sequential searches on certain operations (such as those based on date/time of receipt -- or on folder name). One of the key fields is the "folder name". It is simply a 39-character part of each mail message header record. There's no special data structure that represents a folder -- if the "folder name" field of any record in the mail file contains a particular string, then that folder exists (and any record containing that string in its "folder name" field belongs to that folder. Thus, if you delete all records containing a particular name in the "folder name" field (e.g. by a DELETE/ALL or MOVE/ALL), then there are no more records containing that folder name -- and the folder ceases to exist." (John Osudar) "There's no such thing as an empty folder in VMSmail. The folder name is used as the secondary index into MAIL.MAI; once all the keys for a specific folder are gone, so is all record of that folder. Deleting items individually would produce the same results as delete/all, as would using move instead of delete. The only exception is the wastebasket folder; its name--if different from the default--is explicitly recorded in the user's mail profile and it is recreated as necessary without any confirmation prompt." (Pat Rankin) "MAIL rebuilds the folder structure (on DIR/FOLDER) by scanning all messages noting the folders in use." (Steve Hirby) "This technique turns out to be really convenient for operations like FILE, MOVE (both within the same mail file), and also DELETE (i.e. "file in waste- basket"), since all of these involve no actual movement of the record, but simply an update of the "folder name" field. The behavior you see is one of the side effects. It is true that DEC could have invented a unique record type that would serve as a "folder header", so that even if you delete all the messages in a folder, one record would remain with that folder name. They chose not to do so, probably to avoid the added complication of requiring commands like CREATE/FOLDER, DELETE/FOLDER, etc." (John Osudar) II. What can one do about it? "Now that the DELETE command accepts message numbers and ranges as a parameter, you could just "DELETE 2-" and always leave a message in the folder." (Bruce Hudson) "You might try using MOVE/NOCONFIRM or FILE/NOCONFIRM when you're reorganizing your messages." (Pat Rankin) I have switched to using FILE/NOCONFIRM, with a keypad key redefined for that, and it is a good solution. I really don't care that the folders are recreated anew occasionally, and this command does it transparently - I don't have to respond to the "Do you want to create..." prompt. I still get a message that the folder has been created. III. Acknowledgements: Bruce Hudson pack@acd.ucar.edu (Daniel Packman) Michael Vilain James Harvey Carl J Lydick rankin@EQL.CALTECH.EDU (Pat Rankin) Jerry Leichter "Steve H. - 6553" OSUDAR@cmt.anl.gov (John Osudar {708 252-7505}) GAVRON@ALPHA.SUNQUEST.COM (Ehud Gavron 602-570-2000 x. 2546) j_manning@csc32.enet.dec.com (John Manning) marshall@force.ssd.lmsc.lockheed.com (Bob Marshall) kej@unix.brighton.ac.uk (-* Terminal Rat *-) -- **************************************************************************** * Yosef (Jody) Branse University of Haifa Library * * Mt. Carmel, Haifa 31905, Israel * * Tel.: 972 4-240288 * * FAX: 972 4-257753 * * Israeli U. DECNET: HAIFAL::JODY * * Internet/ILAN: JODY@LIB.HAIFA.AC.IL * ****************************************************************************