Talk:ln (Unix)

The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

Computing: Software / Free and open-source software Low‑importance

	This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing articles
Low	This article has been rated as Low-importance on the project's importance scale.
	This article is supported by WikiProject Software.
	This article is supported by Free and open-source software (assessed as Mid-importance).

COPY VIOLATION?

how much of this page is a copy violation? Or is stuff taken from some *nix documentation that has been released under a compatible licence? NotAnIP83:149:66:11 (talk) 00:33, 22 July 2009 (UTC)[reply]

Er... what exactly do you think has been copied? The GNU man page is not exactly prolix on how to use ln. --Gwern (contribs) 10:18 2 August 2009 (GMT)

Looks like a lot was copied directly from here: http://linuxgazette.net/105/pitcher.html I don't know if their licence covers this sort of use: http://linuxgazette.net/copying.html --DavidMarsh (talk) 02:26, 29 February 2012 (UTC)[reply]

I removed the bulk of the copied and pasted stuff from the main article. (It's also a pretty grievous violation of WP:YOU.) If somebody wants to clean it up and write it back in, here it is:

Usage

The SUS mandates for ln two options: -f will force removal of existing files to allow the link to be created; and -s will create symbolic links. Therefore, ln with no options creates a hard link, ln -f forces a hard link, ln -s creates a symbolic link, and ln -fs forces a symbolic link. In order to link to a folder (vs. a file), use the -n option so that the symbolic link is not dereferenced:

$ ln -sfn existing/folder new/folder/alias

Other Unix and Unix-like operating systems may add extra options. GNU ln adds options such as -b to back up files before creating links, -v to print out the name of each file before links are created, and others. BSD ln adds -h, preventing ln from descending into targets whose symlinks point to directories

$ ln file_name link_name

would have the effect of creating a hard link called link_name that points to the same data as the existing file file_name.

Symbolic link creation and deletion

The following shows the creation of a symbolic link slink.txt:

$ ln -s data.txt slink.txt
$ ls -li
 969768 -rw-r--r-- 1 alex alex   10 Dec  9 09:11 data.txt
 969817 lrwxrwxrwx 1 alex alex    8 Dec  9 09:11 slink.txt -> data.txt

The symbolic (soft) link is stored in a different inode than the text file (969817). The information stored in data.txt is accessible through the slink.txt:

$ file slink.txt
slink.txt: symbolic link to `data.txt'
$ cat slink.txt
some data

If we delete the text file data.txt, slink.txt becomes a broken link and our data is lost.

$ rm data.txt
$ ls -li
 969817 lrwxrwxrwx 1 alex alex    8 Dec  9 09:11 slink.txt -> data.txt
$ file slink.txt
slink.txt: broken symbolic link to `data.txt'
$ cat slink.txt
cat: slink.txt: No such file or directory

Hard link

If hlink.txt was a hard link, our data would still be accessible through hlink.txt. Also, if you delete the original file, the hard-linked copy would still be there:

$ ln data.txt hlink.txt

$ ls -li
  104690 -rw-r--r--   2 sc69876  support      10 Aug 29 18:13 data.txt
  104690 -rw-r--r--   2 sc69876  support      10 Aug 29 18:13 hlink.txt
$ rm data.txt
 
$ ls -li 
  104690 -rw-r--r--   1 sc69876  support      10 Aug 29 18:13 hlink.txt
$ cat hlink.txt
some data

Difference between Hard Link and Symbolic (soft) link

It is requested that a computing diagram or diagrams be included in this article to improve its quality. Specific illustrations, plots or diagrams can be requested at the Graphic Lab.
For more information, refer to discussion on this page and/or the listing at Wikipedia:Requested images.

Unix files consist of two parts: the data part and the filename part.

The data part is associated with something called an "inode". The inode carries the map of where the data is, the file permissions, etc. for the data.

                              .---------------> ! data ! ! data ! etc.
                             /                  +------+ !------+
       ! permbits, etc. ! data addresses !
       +------------inode---------------+

The filename part carries a name and an associated inode number.

                        .--------------> ! permbits, etc. ! addresses !
                       /                 +---------inode-------------+
       ! filename ! inode # !
       +--------------------+

More than one filename can reference the same inode number; these files are said to be 'hard linked' together.

       ! filename ! inode # !
       +--------------------+
                       \
                        >--------------> ! permbits, etc. ! addresses !
                       /                 +---------inode-------------+
       ! othername ! inode # !
       +---------------------+

On the other hand, there's a special file type whose data part carries a path to another file. Since it is a special file, the OS recognizes the data as a path, and redirects opens, reads, and writes so that, instead of accessing the data within the special file, they access the data in the file named by the data in the special file. This special file is called a 'soft link' or a 'symbolic link' (aka a 'symlink').

       ! filename ! inode # !
       +--------------------+
                       \
                        .-------> ! permbits, etc. ! addresses !
                                  +---------inode-------------+
                                                     /
                                                    /
                                                   /
   .----------------------------------------------'
  ( 
   '-->  !"/path/to/some/other/file"! 
         +---------data-------------+
                 /                      }
   .~ ~ ~ ~ ~ ~ ~                       }-- (redirected at open() time)
  (                                     }
   '~~> ! filename ! inode # !
        +--------------------+
                        \
                         '------------> ! permbits, etc. ! addresses !
                                        +---------inode-------------+
                                                           /
                                                          /
    .----------------------------------------------------'
   (
    '->  ! data !  ! data ! etc.
         +------+  +------+

Now, the filename part of the file is stored in a special file of its own along with the filename parts of other files; this special file is called a directory. The directory, as a file, is just an array of filename parts of other files.

When a directory is built, it is initially populated with the filename parts of two special files: the '.' and '..' files. The filename part for the '.' file is populated with the inode# of the directory file in which the entry has been made; '.' is a hardlink to the file that implements the current directory.

The filename part for the '..' file is populated with the inode# of the directory file that contains the filename part of the current directory file. '..' is a hardlink to the file that implements the immediate parent of the current directory.

The 'ln' command knows how to build hardlinks and softlinks; the 'mkdir' command knows how to build directories (the OS takes care of the above hardlinks).

There are restrictions on what can be hardlinked (both links must reside on the same filesystem, the source file must exist, etc.) that are not applicable to softlinks (source and target can be on separate file systems, source does not have to exist, etc.). OTOH, softlinks have other restrictions not shared by hardlinks (additional I/O necessary to complete file access, additional storage taken up by softlink file's data, etc.)

In other words, there's tradeoffs with each.

Now, let's demonstrate some of this...

ln in action

Let's start off with an empty directory, and create a file in it

~/directory $ ls -lia 
total 3
  73477 drwxr-xr-x   2 lpitcher users        1024 Mar 11 20:16 .
  91804 drwxr-xr-x  29 lpitcher users        2048 Mar 11 20:16 ..

~/directory $ echo "This is a file" >basic.file

~/directory $ ls -lia 
total 4
  73477 drwxr-xr-x   2 lpitcher users        1024 Mar 11 20:17 .
  91804 drwxr-xr-x  29 lpitcher users        2048 Mar 11 20:16 ..
  73478 -rw-r--r--   1 lpitcher users          15 Mar 11 20:17 basic.file

~/directory $ cat basic.file
This is a file

Now, let's make a hardlink to the file

~/directory $ ln basic.file hardlink.file

~/directory $ ls -lia 
total 5
  73477 drwxr-xr-x   2 lpitcher users        1024 Mar 11 20:20 .
  91804 drwxr-xr-x  29 lpitcher users        2048 Mar 11 20:18 ..
  73478 -rw-r--r--   2 lpitcher users          15 Mar 11 20:17 basic.file
  73478 -rw-r--r--   2 lpitcher users          15 Mar 11 20:17 hardlink.file

~/directory $ cat hardlink.file
This is a file

We see that:

hardlink.file shares the same inode (73478) as basic.file; hardlink.file shares the same data as basic.file; If we change the permissions on basic.file:

~/directory $ chmod a+w basic.file

~/directory $ ls -lia 
total 5
  73477 drwxr-xr-x   2 lpitcher users        1024 Mar 11 20:20 .
  91804 drwxr-xr-x  29 lpitcher users        2048 Mar 11 20:18 ..
  73478 -rw-rw-rw-   2 lpitcher users          15 Mar 11 20:17 basic.file
  73478 -rw-rw-rw-   2 lpitcher users          15 Mar 11 20:17 hardlink.file

then the same permissions change on hardlink.file.

The two files (basic.file and hardlink.file) share the same inode and data, but have different file names.

Let's now make a softlink to the original file:

~/directory $ ln -s basic.file softlink.file

~/directory $ ls -lia 
total 5
  73477 drwxr-xr-x   2 lpitcher users        1024 Mar 11 20:24 .
  91804 drwxr-xr-x  29 lpitcher users        2048 Mar 11 20:18 ..
  73478 -rw-rw-rw-   2 lpitcher users          15 Mar 11 20:17 basic.file
  73478 -rw-rw-rw-   2 lpitcher users          15 Mar 11 20:17 hardlink.file
  73479 lrwxrwxrwx   1 lpitcher users          10 Mar 11 20:24 softlink.file -> basic.file

~/directory $ cat softlink.file
This is a file

Here, we see that although softlink.file accesses the same data as basic.file and hardlink.file, it does not share the same inode (73479 vs. 73478), nor does it exhibit the same file permissions. It does show a new permission bit: the 'l' (softlink) bit.

If we delete basic.file:

~/directory $ rm basic.file

~/directory $ ls -lia
total 4
  73477 drwxr-xr-x   2 lpitcher users        1024 Mar 11 20:27 .
  91804 drwxr-xr-x  29 lpitcher users        2048 Mar 11 20:18 ..
  73478 -rw-rw-rw-   1 lpitcher users          15 Mar 11 20:17 hardlink.file
  73479 lrwxrwxrwx   1 lpitcher users          10 Mar 11 20:24 softlink.file -> basic.file

then we lose the ability to access the linked data through the softlink:

~/directory $ cat softlink.file
cat: softlink.file: No such file or directory

However, the contents of the original file remain in the hardlink even after the original file has been deleted:

~/directory $ cat hardlink.file
this is a file

MXocross (talk) 07:16, 15 March 2013 (GMT)

Tone issues for the section "Difference b/w Hard Link and Symbolic (soft) link"

First of all, from merely the title you can tell this section isn't quite "Wikipedia material". The writing itself, while valuable, is written in a informal, non-impersonal style, which is my primary concern for this section. Had I a better grasp on links (I landed on this article because of my less-than-stellar understanding), I would rewrite this section in a formal style. I will give kudos to those tight ASCII art diagrams, though. Sadly, I think those would have to go and be replaced by proper SVG diagrams as well. --75.158.16.21 (talk) 22:41, 20 December 2011 (UTC)[reply]

Specification section ln description is wrong or at least ambiguous

In the specification section:

   ln [-fs] [-L|-P] source_file target_file

The problem is that it's not clear in this context what "source" and "target" mean. Compare to the man page for ln:

ln [OPTION]... [-T] TARGET LINK_NAME

Note how the man page regards the existing dir/file as the TARGET, not the source, and explicitly names the other thing the LINK_NAME. I suggest the Wikipedia page be updated to at least not contradict what the man page says, and to be explicit as to which argument specifies the link name/path. Gwideman (talk) 03:10, 23 August 2018 (UTC)[reply]

Yes, this is bullshit. This should either be the way that it is described on the man page or they should both be included so that there is at least a discussion of the confusion over WTF a target is. 69.242.103.243 (talk) 10:49, 29 April 2024 (UTC)[reply]

Thank you for contributing to Wikipeida. However, please see WP:CIVIL and understand that editors should always treat each other with consideration and respect. Cheers, GoldRomean (talk) 02:40, 4 May 2024 (UTC)[reply]