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.

  • Ah, a fellow alumnus! Welcome to Unix.SE! – Stephen Kitt Aug 6 '20 at 7:12
  • Thanks Stephen! :) – occulus Aug 6 '20 at 9:43
  • 1
    Symlinks always work the same way, regardless of how any filesystem internally represents them. (If they're supported at all, e.g. not on FAT). Your Wikipedia quote doesn't include any reason to believe that storing it differently would make a difference. Just a different way of storing the target path string, not extra checking or modifying it when you copy the symlink somewhere. – Peter Cordes Aug 6 '20 at 15:23
  • What filesystem did you have in mind on the optical media? Plain ISO-9660 does not support links of any kind (with the RockRidge extensions it does support symlinks). – marcelm Aug 6 '20 at 17:15
  • 2
    I find it a bit odd that the Wikipedia article makes the storage of symlinks such a major issue. The semantics of the links are the same, and how to store them in the filesystem structures is just about filesystem optimisation. Similar arguments could be made for storing small regular files directly in the inode, or for optimising the storage of the last partial block of regular files of any size, which also has been done in some filesystems. (see: en.wikipedia.org/wiki/Block_suballocation) ln only does whatever the symlink() system call does. – ilkkachu Aug 6 '20 at 19:57

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.


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.


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)

  • 5
    no, they don't seem to mean hard links, and they wouldn't work when copied to another filesystem anyway (or rather, can't be copied as just links) – ilkkachu Aug 6 '20 at 15:17
  • 2
    The advantage of a soft link is not just that it can cross file system boundaries. That's just a convenient corollary. The actual advantage is that it points to a place. When you replace the target file (move away / delete to move another file into place / create it), the symlink points to the new file. A hard link points to a file (inode), so any hard link would continue to point to the deleted/moved file. – cmaster - reinstate monica Aug 6 '20 at 15:18
  • Yes, by symbolic link I mean soft link. Soft links have a 'fast' variant these days, which is what I meant (see the wikipedia quote in the question) – occulus Aug 6 '20 at 16:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.