jkingdon@oberlin.UUCP (Jim Kingdon) (02/21/88)
I don't know about tricks with fooling it about fake directories and stuff. VMS has command SET FILE/ENTER, which creates a hard link, and SET FILE/REMOVE which removes one. The big difference with UNIX is that if you SET FILE/REMOVE the last reference to a file, instead of deleting the file, those disk blocks just sit there until you reformat the disk. I'm pretty sure that there are RMS calls to do this stuff from a program too, but I've never used this stuff much.
thornton@topo.UUCP (Ron Thornton) (02/22/88)
In article <691@oberlin.UUCP> jkingdon@oberlin.UUCP (Jim Kingdon) writes: >and SET FILE/REMOVE which removes one. The big difference with UNIX >is that if you SET FILE/REMOVE the last reference to a file, instead >of deleting the file, those disk blocks just sit there until you >reformat the disk. I'm pretty sure that there are RMS calls to do Recovering the disk space requires ANALYZE/DISK_STRUCTURE to pickup lost files, not a full reformat. The /REMOVE removes directory entries but leaves the file header intact in INDEXF.SYS where analyze can find it. If FILES-11 would just learn to keep a link count, Unix style links might work. -Ron-
ted@blia.BLI.COM (Ted Marshall) (02/23/88)
In article <691@oberlin.UUCP>, jkingdon@oberlin.UUCP (Jim Kingdon) writes: > ... VMS has command SET FILE/ENTER, which creates a hard link, > and SET FILE/REMOVE which removes one. The big difference with UNIX > is that if you SET FILE/REMOVE the last reference to a file, instead > of deleting the file, those disk blocks just sit there until you > reformat the disk. ... If you already understand SET FILE/ENTER and SET FILE/REMOVE, you can skip the rest of this message. There have already been several messages explaining what they do, but this posting shows that there are still many people who don't understand the details. Therefore I decided to post a concise explanation. The VMS file system, somewhat like UNIX, has a master list of all files on a disk volume (called INDEXF.SYS). This is indexed by file identification (FID). There are also directory files which relate directory and file name to FID. Thus, if you have a file, for example, "[X]Y.Z", the directory file "[000000]X.DIR" contains an entry for the name "Y.Z" and the corresponding FID. There is also an entry in INDEXF.SYS under that FID containing the rest of the information for that file, including pointers to the file data. Also included is ONE "back pointer" to a directory entry containing that FID. Normally a file has one directory entry and the back pointer points to that. SET FILE/ENTER adds another directory entry with the same FID. Here is the big difference from UNIX: the back pointer is not changed and there is no information add to INDEXF.SYS saying that there is a second directory entry with that FID. SET FILE/REMOVE deletes an entry from a directory without affecting INDEXF.SYS. If the last directory entry for a file is removed, it becomes a "lost" file. The file still exists, it is still charged to the owner's quota and can still be accessed by FID, but it is not in any directory. It can be recovered using the VERIFY utility (ANALYZE/DISK command) which will put it in a specific system directory (sorry, I can't remember its name) under one of its former names (info stored in the index entry) where it can be returned to its owner or deleted. DELETE deletes a directory entry and the associated index entry and file data. If there are additional directory entries, they now contain invalid FIDs (note that FIDs include sequence numbers, so a specific FID will not be re-used for a long time). If you do a directory on that file name, requesting more than just file name, type and version you will see: $ DIR/SIZE Y.Z Y.Z;1 no such file This means that the directory entry exists, but the resulting FID does not specify a current file. This directory entry can be removed by SET FILE/REMOVE. -- Ted Marshall ...!ucbvax!mtxinu!blia!ted <or> mtxinu!blia!ted@Berkeley.EDU Britton Lee, Inc., 14600 Winchester Blvd, Los Gatos, Ca 95030 (408)378-7000 The opinions expressed above are those of the poster and not his employer.
dave@wsccs.UUCP (Dave E Martin "VAX Headroom") (03/02/88)
In article <691@oberlin.UUCP>, jkingdon@oberlin.UUCP (Jim Kingdon) writes: > is that if you SET FILE/REMOVE the last reference to a file, instead > of deleting the file, those disk blocks just sit there until you > reformat the disk. I'm pretty sure that there are RMS calls to do > this stuff from a program too, but I've never used this stuff much. You don't need to reformat the disk, try analyze/disk_structure/repair with an optional /confirm. I recommend one of these every now and then. (say once every few reboots). this will get rid of temp files that existed without a real filename when the system crashed too.