Path: utzoo!attcan!uunet!husc6!bbn!uwmcsd1!ig!agate!ucbvax!CITHEX.CALTECH.EDU!carl From: carl@CITHEX.CALTECH.EDU (Carl J Lydick) Newsgroups: comp.os.vms Subject: RE: Uses for access time Message-ID: <880506120409.1d20@CitHex.Caltech.Edu> Date: 6 May 88 19:17:50 GMT References: <8805021633.AA19865@scgvaxd.SCG.HAC.COM> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 25 > Yes. These are reasons enough. Security (knowing whether a file has > been modified, and when) is a singular "reason enough!" One of the other > important reasons for recording last-access time (most especially > last-modified time) is for backup purposes. Performing an incremental > backup would be difficult without knowing which files had changed at what > times. An operating system ~could~ just maintain a one-bit flag for each > file indicating 'file-modified', and reset the bit each time the file was > backed-up. But this austere method eliminates security tracking and > precludes any flexibilty on selective backups (by date/time) {in the words > of Yul Bryner: etc, etc, etc...} I'm afraid that Brian Hagerty is missing the point. The question was about last access time, as distinct from last modification time. There are, as he states, very good reasons for maintaining a last modification time. Last access time is less clearly useful unless you're running in a pretty secure environment and need to know if someone has seen something he shouldn't. The main use I've seen for maintaining a last-access time for a file is for archiving purposes: if nobody's used a file for a long time, you might want to move it to tape. If you've got only a few sensitive files, you can put alarm acl's on them. For archiving purposes, you don't need to keep close track of the last access time; you need a resolution equal to how long it can be since a file has been accessed before you want to archive it. This can be done by setting the retention period on the volume (on CITHEX, this is 6 months minimum, 6 months and a day maximum).