[Info-vax] Request description of UFS for VMS person

[AEF]

On Apr 20, 9:45 pm, moro... at world.std.spaamtrap.com (Michael Moroney)
wrote:
> AEF <spamsink2... at yahoo.com> writes:
> >Then there's the mysterious VMS deletion process which I'd love to
> >learn. I only know about it from the strange ANAL/DISK errors about
> >file headers being busy, deleted, quasi-deleted, or whatever. I'd love
> >to learn about that too. [Fuzzy-memory-of-a-long-ago-event alert!] I
> >once learned a little about it and kept a sample lying around, but
> >it's been so long I can't recall just what that was! Wait, I think it
> >was a file header without a filename being entered in any directory.
> >If I have time I'll try to resurrect this. [Another fuzzy-memory-of-a-
> >long-ago-event alert!] I think I even asked this question (re the file-
> >deletion process) here once many years ago and if I did I never got a
> >good answer.
>
> Yes, on VMS a file can exist without being in any directory.  By speaking
> the right magic to RMS a program can create a file not in any directory.
> It can be pre-deleted as well, see below.  The file exists because a
> header in INDEXF.SYS says it does.
>
> There is a bit in the file header that says the file has been deleted.
> It exists for valid files.  This may seem to be a contradiction, but the
> bit really means "delete this file when the last accessor closes this
> file".  This bit being set causes ANALYZE/DISK to complain.
>
> What the familiar $ DELETE command really does is to open the file, set
> the deleted file bit and close it.  99.9% of the time the DELETE command
> is the only thing accessing the file, so it is the last (only) accessor
> of it when DELETE closes the file.  It is here that the file system does
> the real deletion of the file (frees the header, used blocks etc).
> If some other program also has the file open, the file is _not_ deleted
> when DELETE closes it.  It will be deleted when it (or the last accessor)
> closes it.  If the system crashes, the file is never closed and lives on
> as a zombie file, not in any directory, supposed to be deleted but still
> there, until $ ANALYZE/DISK finds it and /REPAIR does something about it.
>
> RMS can create files not in any directory.  This is normally used for
> temporary files.  By setting the deleted file bit these files are
> automatically deleted on a close (including abnormal termination) so this
> is useful to keep the file system clean.

Thanks! I thought it was something like that but also thought that
based on the several different ANAL/DISK messages that it was more
complicated than that. Perhaps I was including the missing directory
entry type of messages in that count.

Thanks for your help!