VMS ODS-5 symlinks are a POS IX. The support in the Linux ods5 file system is limited or maybe I should say experimental. Following symbolic links is off by default. To get symlink support, mount with -o syml On VMS (with the default settings for a process, that is after a "set process/parse/case"): $ copy tt: hello Hello World! [ Exit ] $ create/symlink="hello" world This results in the files HELLO.;1 and WORLD.;1 with world containing "hello" as a symbolic link. And a $ type world. Hello World! $ gives the somehow expected result. The problem here is, the symbolic link, the contents of WORLD.;1, is not an ODS-5 filename! How can the Linux ods5 file system ever find this? The lookup method is an inode operation and now has to find both, ODS-5 files with version and - as a result of following a symbolic link - the last version of an ODS-5 file without a version specified or even a directory file without the .DIR type. Simplified, this is done with looking for the version delimiter. If the ods5_lookup sees it, then we do an ordinary lookup, if it sees none, then we do a symbolic link lookup. Even with sophisticated checks if the ';' delimits a version number, this creates several problems 1. A symbolic link to a file "a.b;1" which is the ODS-5 target "a.b^;1;0" will incorrectly lookup the different ODS-5 file "a.b;1". 2. Version-less file specifications are allowed and show as such! This was never intended! But with file completion the versions are added. 3. Dirless directories work! This was intended to be available only with a separate option. But with file completion the .DIR type is added. 4. The option dotversion makes this more complicated. Symbolic links to ODS-5 files like "a.b^;1;1" are likely rare. Symbolic links to ODS-5 files like "a.1" are probably more common. Both will not be correctly resolved. Therefore, syml disables dotversion and the check for a version is simply the check for any ";" in a filename.