Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I can read in the ln man page:

   -L, --logical
          make hard links to symbolic link references

I read somewhere that ln -L could be used to re-link files that were deleted but which are still open, using the /proc filesystem. For example:

ln -L /proc/1234/fd/12 /tmp/my-file

But I'm getting ENOENT: No such file or directory. If I try on a different filesystem, I get instead Invalid cross-device link.

If I can't use ln -L to recover deleted files, then what could it be used for?

share|improve this question
up vote 4 down vote accepted

GNU utilities are primarily documented with info pages. From the GNU ln info page:

    If -s is not in effect, and the source file is a symbolic link,
    create the hard link to the file referred to by the symbolic link,
    rather than the symbolic link itself. 

So this simply dereferences symbolic links given as source arguments.

share|improve this answer

Well, a little bit more newbie-friendly answer...

Some basics beforehand

A simple view on how files are stored on UNIX/Linux systems is: There's a directory entry consisting of the name you see with ls -l and an Inode number (you may see with ls -i). The Inode contains the actual information where your data is stored on the filesystem (among other things like ownership, permissions, more Inodes if neccessary, and so on):

(Time for some UTF-8 fun... ;-) )

Simple view:

┌─────────────────┐    ┌───────┐    ┌─────────────┐
│ directory entry │ ─► │ Inode │ ─► │ data blocks │
└─────────────────┘    └───────┘    └─────────────┘

Now to the difference between Hard and symbolic link:

A hard link is simply a directory entry that points to the same Inode as an already existing one, whereas a symbolic link is just a special file that contains the name of annother file (stored directly within the Inode, if the pathname is small enough to fit in). This is the reason, why

  • Hard links to the same file cannot have different file access permissions (since these are stored within the Inode)
  • Hard links must reside within the same file system

Expanded simple view

 │    hard link    │ ───────┐
 └─────────────────┘        ▼
 ┌─────────────────┐    ┌───────┐    ┌─────────────┐
 │  example_file   │ ─► │ Inode │ ─► │ data blocks │
 └─────────────────┘    └───────┘    └─────────────┘
 ┌─────────────────┐    ┌─────────┴──────────┐
 │  symbolic link  │ ─► │ filename reference │
 └─────────────────┘    └────────────────────┘

Now back to the -L option with -s absent: It allows you, to create a hard link of a file where a symbolic link points to (Like "hard link" in the example above).

Why could that help to recover files which have been deleted, but are still used by an open program?

Well the behaviour of this is surely very implementation dependent and your mileage may vary across all the UNIX/Linux platforms, but I'll try to explain how it could work:

When a file gets deleted (let's say via rm(1)) the system call called is always unlink(2). It removes the directory entry and reduces the link counter (maintained within the Inode) by one.

If the link counter reaches zero, it's time for the OS to clean up (actually release the data blocks where the inode points to and then the Inode itself. BUT if the file ist still open, this taskis normally deferred until the program using the inode terminates.

Nowadays the most UNIX systems maintain a /proc filesystem hierarchy where one may lookup references to open files, which are (surprise!) symbolic links. Given that one finds the correct entry, ln -L may help to recreate a link to the inode, increasing the link counter again and thus prevent the OS from deleting the inode (if the lucky user is quick enough and the program is still running).

Note: For this to work, the new link's location must be on the same filesystem on which the original has been!

Final Example

 │   rescue_link   │ ───────┐
 └─────────────────┘        ▼
 ┌─────────────────┐    ┌───────┐    ┌─────────────┐
 │ *** removed *** │    │ Inode │ ─► │ data blocks │
 └─────────────────┘    └───────┘    └─────────────┘
 ┌─────────────────┐    ┌─────────┴──────────┐
 │ /proc/bla/fd/n  │ ─► │ filename reference │
 └─────────────────┘    └────────────────────┘

Final words

There are plenty of things that may prevent the correct creation of the link and it's very dependent on how the symbolic link itself is implemented and I have to admit: I have serious doubts it will work with many UNIX variants - but maybe a volunteer who's willing to spend some time to test this?

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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