perm filename ARCHIV.TXT[NET,GUE] blob sn#032736
filedate 1973-03-30 generic text, type T, neo UTF8
Basic User Information Concerning the ISI File Archival System
The ISI TENEX will soon support a file archival facility. This memo
should provide all users with enough information to utilize the archive.
The purpose of the archive is twofold 1) it provides each user with
a large, long-term storage capability and 2) it provides the
system with a mechanism for freeing online storage.
This first implementation has several recognized disadvantages. It is
neither as general nor as automatic as we would like it to be. The
archival mechanism will require operator assistance for both entering
and retrieving files. We will be refining the archival facilities
during the following months.
We are instituting the archive primarily for reason (2) above.
Examination of the file system indicates that approximately 35% of the
current disk storage has not been read or written in 30 days. We plan
to allow all files to "age" in the user's directory for approximately
this period of time. Files so "aged", neither read nor written for a
month, will be copied several times to the magtape archive, verified,
and deleted from the user's directory. The location of the file will
be recorded (see INTERROGATE below) so that the user will be able to
notify the operator of a retrieval request.
Note that referencing a file will remove its archival candidacy and
restart its ageing, thereby delaying its archival. We suggest that
artifical referencing, done only to prevent archival, not be done.
Circumventing archival will lead to a directory cluttered with files
which are unnecessarily online. Since we will soon be ENFORCING DISK
ALLOCATIONS, a cluttered, over-allocated directory will result in an
inability of the user to do any useful work. The suggested and
encouraged mode of use is simply to let files age themselves into the
archive or to request, via the ARCHIVE command (below), the archival of
files known to be not in active use.
The following commands have been implemented in the EXEC to support
user use of the archive:
The ARCHIVE command provides the user with a method for setting archive
requests, resetting archive requests, and determining if a file is in
the process of being archived (a file may remain in a user directory
with the archival request set for several days, depending upon how often
the archive utility is run by the operator).
this command queues a request that the user's file file.ext;ver
be archived; the file remains in the user's directory until
successful archival; after being archived, the file will be
deleted from the user's directory; * is legal in any field
a comma at the end of the file specification invokes
Current subcommands are:
this tells the system to never archive the specified
this tells the system to not delete the file from the
directory after it has been successfully copied to
this tells the system to undo all archival requests
for the specified file (analogous to the UNDELETE command)
this requests that the current archival status of the specified
file be typed (the file may not be fully archived -- it
may have been only copied to the archive tape once)
As with other EXEC subcommand modes, two carriage returns confirm the
execution of the ARCHIVE command whenever subcommands have been
The INTERROGATE command is used on a fully archived file.
interrogates the archive; if the specified file is not
found, THAT FILE IS NOT ARCHIVED is typed out; if the
file is found, ARCHIVED ON TAPES MMM AND NNN is typed out;
if found, DO YOU WANT IT RETRIEVED? is also typed out;
if the answer is yes, a message will be printed on a special
teletype in the computer room; the operator will periodically
check for such requests; when the file has been retrieved,
the retrieval will be confirmed via LINK if the requestor is
still logged in, or via SNDMSG if not