Create old style 'slow' symbolic links

Question

ln -s creates 'fast' symbolic links. These break if you copy them (and their targets) to e.g. optical media. I believe old style 'slow' symbolic links would work, but how can I create them? There's no ln flag or other command that I can find.

Some info for context, from the wikpedia page on symbolic links:

Early implementations of symbolic links stored the symbolic link information as data in regular files. The file contained the textual reference to the link's target, and the file mode bits indicated that the type of the file is a symbolic link.

This method was slow and an inefficient use of disk-space on small systems. An improvement, called fast symlinks, allowed storage of the target path within the data structures used for storing file information on disk (inodes). This space normally stores a list of disk block addresses allocated to a file. Thus, symlinks with short target paths are accessed quickly. Systems with fast symlinks often fall back to using the original method if the target path exceeds the available inode space. The original style is retroactively termed a slow symlink. It is also used for disk compatibility with other or older versions of operating systems.

Answer 1

There’s no way to tell ln to create “fast” or “slow” symlinks, the file system determines how it stores symlinks.

Dealing with symlink representation on optical media is up to the program handling the conversion, or the file system driver providing access to the medium, not up to the source file system. For example, mkisofs can use Rock Ridge extensions or TRANS.TBL files to represent symlinks. It can also handle hard links.

Answer 2

Your assumption that "fast" and "slow" symbolic links behave differently is incorrect. Both simply store the destination path as text. The optimization here is to use space in the directory entry to store that text, if it is short enough. If the path is too long, the file system will transparently use another block to store the path, just like it would use another block to store the content of a file. This is slower because it requires two reads from the disk, but in practice you'll rarely notice the difference. This is especially true if you have an SSD or NVMe drive.

You might instead use a relative path for the symlink. When you copy the files to another disk, the symlink will continue to work as expected as long as the source and destination have the same relation to each other. As a bonus, the relative path might be shorter than an absolute path, and thus more likely to fit within the directory entry.

Answer 3

Perhaps you mean "hard" and "soft" links? Only the "soft" link is symbolic. The hard link works the inode reference into the directory just like a "regular" file.

In theory the "hard" link is faster, but the "soft" link has the advantage of being able to cross filesystems.

If you want a hard link, the command is ln without the -s flag, and there are conditions where the link cannot be created. With the -s flag, a soft-link or a file that contains the path of the other file (in a special format) is created. This symbolic link is slower, but only by a little bit; because, the OS needs to open the file to read the new path, and then re-request the file at the path it read. With a hard link, the directory entry points directly at the file, so the multi-step operation above doesn't happen, it just goes directly to the first block of the file.

As for the "slow" / "fast" symbolic links, they are now a bit of history. Most filesystems have space in their inode tables of their directories. If the file is small enough to fit into the inode table itself, the file isn't created with its own block number, but rather a flag is set in the inode table and the contents of the file is stored in the inode entry directly. This only works for very small files, and symlinks are one of those kinds of files.

Since you can't tell the operating system how to store data in the filesystem at this level, the ways you could force one storage approach or another is limited. You could, for example, use a really long path to ensure you overflow the inode entry storage. Likewise, you could write a program that modifies the disk blocks bypassing the regular filesystem libraries (of course, you'd also have to work around the OS management of the same, because it will try to deny such actions since updating the file system is the OS's responsibility)