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?
