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

[JF Mezei]

Bob Eager wrote:
> My point in mentioning 'clri' is that someone here 
> thought that functionality was essential on VMS to tidy up a borked 
> directory, and (by implication) that 'Unix' was broken if it couldn't do
> it. In practice, it seems that VMS *needs* it and Unix doesn't.


It would be interesting to get some historical perspective on why VMS
engineering added that command.

If you have a corrupt .DIR file, then perhaps STE FILE/NODIR followed by
ANA/DISK/REPAIR would recover the file which you could put back into a
new directory of the same name.

Remember that there were times when adding too many files to a directory
caused the directory files to no longer support being extended. Perhaps
there were times in the early days of VMS where a directory file could
become unusable even to delete/rename files off that directory.


BTW, I have another question about the Unix file sytstem:

I can have a directory file /disk2/jfmezei  which can contain unix files
and subdirectories.

I can then mount  nfs://10.0.0.11/disk2/vanilla  /disk2/chocolate

At that point, doing  ls /disk2/chocolate will list the "vanilla" files
on the remote system. So the mount point essentially overwrites an
existing directory, making the files under it inaccessible.

But, when I umount /disk2/chocolate, it will remove the link to the
vanilla files on the remote system, and by magic, /disk2/chocolate will
again list the chocolate files ?

How do they preserve the original contents of the chocolate directory
when chocolate becomes a mount point ?

Is it the chocolate entry in the /disk2 diretory which is updated, or it
is the /disk2/chocolate file which is updated to have an extra entry
(the mount point) which causes all other files in that directory to
become invivisible ?