NetNews Usenet Archive 1992 #18/NN_1992_18.iso/spool/comp/os/vms/13757

Internet Message Format | 1992-08-18 | 7.7 KB

Xref: sparky comp.os.vms:13757 comp.mail.misc:2686
Newsgroups: comp.os.vms,comp.mail.misc
Path: sparky!uunet!das.wang.com!wang!news
From: [e-mail] (Yosef Branse)
Subject: VMS/MAIL - Summary of Replies to DELETE/ALL Query (13-Aug)
Organization: Haifa University Library
Date: Tue, 18 Aug 1992 12:57:28 GMT
Message-ID: <[e-mail]>
Sender: [e-mail]
Lines: 136

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 <[e-mail]>
[e-mail] (Daniel Packman)
Michael Vilain <[e-mail]>
James Harvey <[e-mail]>
Carl J Lydick <[e-mail]>
[e-mail] (Pat Rankin)
Jerry Leichter <[e-mail]>
"Steve H. - 6553" <[e-mail]>
[e-mail] (John Osudar {708 252-7505})
[e-mail] (Ehud Gavron 602-570-2000 x. 2546)
[e-mail] (John Manning)
[e-mail] (Bob Marshall)
[e-mail] (-* Terminal Rat *-)
--
****************************************************************************
* Yosef (Jody) Branse             University of Haifa Library              *
*                                 Mt. Carmel, Haifa 31905, Israel          *
*                                 Tel.: [phone]                       *
*                                 FAX:  [phone]                       *
* Israeli U. DECNET: HAIFAL::JODY                                          *
* Internet/ILAN:     [e-mail]                                  *
****************************************************************************