9

Both Unix and Windows, quite early, acquired cross-links in their filesystems, such that the filesystems are not trees, but general directed graphs. I'm curious about whether this was an inevitable development, or a contingent historical event. The best test of this would be to find a general-purpose operating system with a hierarchical filesystem, whose development was as independent as possible of the above. VMS looks like the best candidate.

So, did VMS ever acquire filesystem cross-links?

And if so, did it happen before or after Dave Cutler left? That would be interesting because if it was before, it would suggest Windows NT got the idea not from Unix as I had assumed, but from VMS.

Improve this question
5
  • 2
    It did with ODS-5, but it was never popular.
    – RonJohn
    Commented Feb 14 at 13:09
  • 1
    "it would suggest Windows NT got the idea not from Unix as I had assumed, but from VMS." - surely any halfway-competent file system designer was aware of Neumann and Daley's seminal 1965 paper which proposed links, though it had what in the light of subsequent work I'd call an unnecessary distinction between branch (=file) and link. And Cutler wasn't the designer of NTFS; from what I know of his work, I'd guess that's too high-level (in an architecture layering sense) to be of interest.
    – dave
    Commented Feb 14 at 22:55
  • Once I knew it so that VMS has no links et al. And it also had no file rename, files had to be copied. Beside these, file also had a version, and the system stored all previous version of all previous files.
    – peterh
    Commented Feb 15 at 19:25
  • @peterh DCL definitely had RENAME, though it was restricted to the same device the file was on. Unix mv has the same restriction; it’s inter-device mv is really copy/delete.
    – RonJohn
    Commented Feb 20 at 2:29
  • 1
    @peterh, just to be clear, VMS did not ensure keeping every previous version. While the default behaviour when creating a file was to give it the next higher version number than the current (or 1 if no current), it was quite easy to use something like purge file.ext /keep=3 to remove older versions. Otherwise, disks would have filled up, or your disk quota would have become exhausted, rather quickly :-)
    – paxdiablo
    Commented Mar 2 at 9:15

2 Answers 2

Reset to default
14

Even ODS-1 on RSX-11D and RSX-11M, ancestors of VMS running on the PDP-11, could have cross-links, but you wouldn't want to.

What made this possible was the separation of low-level APIs for file creation and for entering a link in a directory. Given an existing file, you could add additional directory entries. See the .ENTER macro on page 4.14 of the I/O ops manual.

The swiss-army-knife program PIP exposed this as /EN, create directory entry. See page 2-15 of the utilities manual. From that page:

Tne ENTER command provides the facility to enter a synonym for a file in a directory or directories, thus allowing the file to be accessed by more than one name.

The code for manipulating directory entries was in the user-space File Control Services (FCS) library rather than in the file system proper (F11ACP). There was even a utility for sorting a directory, i.e., arranging the entries in alphabetical order. This seemed to be purely an aesthetic preference.

The file system did not implement a link count for a file. Therefore, deleting the file from any one of its directory entries left the rest of them dangling. Fortunately, there was a 'remove' operation (the reverse of 'enter') for you to mop up the mess you'd created.

What's this to do with VMS per the question? Well, the initial VMS file system was ODS-1 from RSX and IAS, with much of the utility code running in compatibility mode. So I'm pretty sure any VMS system running ODS-1 had the same (mis)feature. I'm almost as sure that ODS-2, which added named directories (ooh!) would have been the same.

One thing to note about VMS is that the average program did not deal with the file system level directly, but used Record Management Services (RMS) on top of the file system. I don't recall whether a bare 'enter' was exposed through RMS.

You used all this at your peril, however.

As to whether it was an inevitable development: here it is more like an accident from layering, in that it is the job of the file system to have files (identified by index entry, like inodes in other system) and the job of something else to manipulate directory entries.

(Caveat: much of this is from memory, so fine details of implementation might be incorrect).

Improve this answer
3
  • 2
    Ref: $ENTER RMS service on page 215 of the VSI OpenVMS Record Management Services Reference Manual.
    – HABO
    Commented Feb 15 at 1:55
  • 1
    Of course, if you need to do it from DCL you would use SET FILE/ENTER to add a link and SET FILE/REMOVE to make it go away without taking the file along. (Heading out in the morning to reincarnate an Alpha with a failing hard drive.)
    – HABO
    Commented Feb 15 at 3:53
  • My excuse: I last touched VMS about 30 years ago :-)
    – dave
    Commented Feb 15 at 3:57
10

OpenVMS added support for hard links in ODS-5 volumes with hard links enabled, in version 7.2 (released in February 1999, long after Dave Cutler’s departure).

This is older than proper support for hard links in Windows NT, where they only became usable for end-user programs using a default setup on Windows Vista (2006–2007). Symbolic links have been available for directories since Windows 2000, and for files since Windows XP, but they have also only been usable in practice since Vista. Junction points were available in Windows 2000 and more generally usable, and even DOS had somewhat similar features (using JOIN and SUBST, but still a far cry from actual links).

Improve this answer
6
  • 1
    For a not-quite-the-same comparison, VMS had 'logical names', which sort-of insulated the programmer from the actual tree structure, and which were heavily (excessively?) used.
    – dave
    Commented Feb 14 at 22:44
  • 4
    As a programmer who wrote exec-level code on NT (file system drivers for ill-thought-out ideas, or maybe good ideas with idiotic execution), it always seemed to me that the base system guys built in loads of useful stuff that the Win32 subsystem just didn't know what to do with.
    – dave
    Commented Feb 14 at 23:01
  • 1
    @dave: That's probably due to NT's history of being a highly-portable (meaning it should be easy to swap out the hardware "below" the kernel) and multi-personality (meaning it should be easy to swap out the OS "above" the kernel) system. After all, it was originally meant to be a successor to OS/2, not a new version of Windows. During its early years, it supported DOS, Windows (16-bit), Win32, OS/2, and POSIX as "personalities" and x86, MIPS, Alpha, and SPARC as platforms (with original development done on i860). It is probably natural that not every personality uses every feature.
    – Jörg W Mittag
    Commented Feb 15 at 11:24
  • 1
    XP definitely had working support for hard links (fsutil.exe could create them). On the other hand, its IO_REPARSE_TAG_SYMLINK support seems to be just barely mentioned in the available source code – was it actually functional before Vista in any manner?
    – grawity
    Commented Feb 15 at 21:16
  • 1
    @dave logicals were stupendously useful. Soooo many management tasks would be easier if they existed In Linux.
    – RonJohn
    Commented Feb 20 at 2:36

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .