Linux - NewbieThis Linux forum is for members that are new to Linux.
Just starting out and have a question?
If it is not in the man pages or the how-to's this is the place!
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
-- er, uh, or 'ls -l' and look at the second column. Sorry. I have to make everything complicated. 1's a normal file and 2+ is a hard link for a regular file.
I think a hard link is an alternate name pointing to the same inode as the original and, after that, they are indistinguishable. Whereas a symlink is just a small file containing a path, basically - it's only a pointer to the original. 'Symlink' is just another name for a 'soft link'.
Well, the contents of your actual directory is data on a disk. The system keeps track of it by inode number. The 'filename' you use is kind of like a user-friendly domain name like 'linuxquestions.org' when the system actually finds stuff by IP number. Both filenames are just descriptions of the inode. If you do 'touch foo; ln foo bar; stat foo bar' you'll see they're identical. Then do 'echo baz >> bar' and stat again - still the same - and then 'rm foo' and 'cat bar' and it'll still print 'baz'.
So long story short, no, deleting one won't delete the contents - just remove a reference name.
I really don't know. I mean, there may be technical issues I'm not aware of. The only benefit I can think of is that you can't have a broken hard link. If you move the original, the symlink will break and, if you create a symlink with a relative path and move it, it'll break. But I've never seen the need to use one. I *think* symlinks were introduced later than hardlinks, so maybe you could just look at them as a replacement mechanism for similar functionality that's maybe a better mechanism. It's no trouble to link across filesystems or to keep straight what's a link and what isn't and so on. So stability of hard links is about all I can think of.
The command for both is 'ln' - kind of indicating which has priority: to make a sym/softlink, you have to add the option '-s', like 'ln -s' and to make a hard link, it's just 'ln'. But it's the same command.
-- er, uh, or 'ls -l' and look at the second column. Sorry. I have to make everything complicated. 1's a normal file and 2+ is a hard link for a regular file.
3 is a hard link on all my opensuse systems...
Landis.
One obvious benefit is that when you delete the original file, the hard link still allows you to access the file. A soft link would just be broken and the file would be gone.
Some backup utilities (e.g. storebackup) make use of this to create an archive of old backup states, which only consist in hard links. You can e.g. have daily snapshots of your home directory for one week. If nothing changes, they would not consume more space then just one single copy. Still you can delete any one of these snapshots and all the others are still intact.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.