Editing Symbolic link (section)

==POSIX and Unix-like operating systems==
In [[POSIX]]-compliant operating systems, symbolic links are created with the <code>symlink</code><ref>[https://pubs.opengroup.org/onlinepubs/9699919799/functions/symlink.html symlink, symlinkat]. IEEE Std 1003.1, 2013 Edition.</ref> system call.  The <code>[[ln (Unix)|ln]]</code> shell command normally uses the <code>link</code><ref>[https://pubs.opengroup.org/onlinepubs/9699919799/functions/link.html link, linkat]. IEEE Std 1003.1, 2013 Edition.</ref> system call, which creates a [[hard link]].  When the <code>ln ''-s''</code> flag is specified, the symlink() system call is used instead, creating a symbolic link. Symlinks were introduced in 1982 in [[Berkeley Software Distribution|4.1a BSD Unix]] from [[Computer Systems Research Group|U.C. Berkeley]].<ref>{{cite web |author1=Bill Joy |author2=Sam Leffler |author1-link=Bill Joy |author2-link=Samuel J. Leffler |title=Surviving with 4.1a bsd |website=[[GitHub]] |url=https://github.com/dspinellis/unix-history-repo/blob/BSD-4_1c_2/usr/man/man0/changes.4-82#L28 |access-date=8 September 2023 |quote=It also includes a few other features which you may find useful, such as ‘‘symbolic links’’ and an improved group scheme.}}</ref>

The following command creates a symbolic link at the [[command-line interface]] (shell):
<pre>
 ln -s target_path link_path
</pre>
{{mono|target_path}} is the relative or absolute path to which the symbolic link should point.  Usually the target will exist, although symbolic links may be created to non-existent targets. {{mono|link_path}} is the path of the symbolic link.

After creating the symbolic link, some operations can be used to treat it as an alias for the target. However, the <code>lstat</code>,<ref>[https://pubs.opengroup.org/onlinepubs/9699919799/functions/fstatat.html fstatat, lstat, stat - get file status] IEEE Std 1003.1, 2013 Edition.</ref> <code>lchown</code><ref>[https://pubs.opengroup.org/onlinepubs/9699919799/functions/lchown.html lchown - change the owner and group of a symbolic link] IEEE Std 1003.1, 2013 Edition.</ref> and <code>readlink</code><ref>[https://pubs.opengroup.org/onlinepubs/9699919799/functions/readlink.html readlink, readlinkat - read the contents of a symbolic link] IEEE Std 1003.1, 2013 Edition.</ref> operations are unique to symbolic links and do not apply to the target; by using those system calls, programs that examine the file system (e.g., <code>[[ls]]</code>, <code>[[find (Unix)|find]]</code>) can report on symbolic links (instead of their targets, if any).  Because the <code>rename</code> and <code>[[unlink (Unix)|unlink]]</code> system calls are coded to operate directly on symbolic links, file system management commands (e.g.,  <code>[[rm (Unix)|rm]]</code>, <code>[[mv (Unix)|mv]]</code>) affect the symbolic link itself (instead of being applied to the symbolic link target, if any).  The <code>rm</code> (delete file) command removes the link itself, not the target file. Likewise, the <code>mv</code> command moves or renames the link, not the target. The <code>[[cp (Unix)|cp]]</code> command has options that allow either the symbolic link or the target to be copied. Commands which read or write file contents will access the contents of the target file.

The POSIX directory listing application, <code>ls</code>, denotes symbolic links with an arrow after the name, pointing to the name of the target file (see following example), when the long directory list is requested (<code>-l</code> option). When a directory listing of a symbolic link that points to a directory is requested, only the link itself will be displayed. In order to obtain a listing of the linked directory, the path must include a trailing directory separator character ('/', slash).
 
Note: In the example below do not create "three" directory before creation of link in /tmp directory.
<syntaxhighlight lang="console">
$ mkdir -p /tmp/one/two
$ echo "test_a" >/tmp/one/two/a
$ echo "test_b" >/tmp/one/two/b
$ cd /tmp/one/two
$ ls -l
-rw-r--r-- 1 user group 7 Jan 01 10:01 a
-rw-r--r-- 1 user group 7 Jan 01 10:01 b

$ cd /tmp
$ ln -s /tmp/one/two three
$ ls -l three
lrwxrwxrwx 1 user group 12 Jul 22 10:02 /tmp/three -> /tmp/one/two
$ ls -l three/
-rw-r--r-- 1 user group 7 Jan 01 10:01 a
-rw-r--r-- 1 user group 7 Jan 01 10:01 b

$ cd three
$ ls -l
-rw-r--r-- 1 user group 7 Jan 01 10:01 a
-rw-r--r-- 1 user group 7 Jan 01 10:01 b
$ cat a
test_a
$ cat /tmp/one/two/a
test_a
$ echo "test_c" >/tmp/one/two/a
$ cat /tmp/one/two/a
test_c
$ cat a
test_c
</syntaxhighlight>

===Storage of 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 storage|disk-space]] on small systems.  An improvement, called '''fast symlinks''', allowed storage of the target path within the [[data structure]]s used for storing file information on disk ([[inode]]s). This space normally stores a list of disk [[Block (data storage)|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 [[retronym|retroactively termed]] a '''slow symlink'''. It is also used for disk compatibility with other or older versions of operating systems.

Although storing the link value inside the inode saves a disk block and a disk read, the operating system still needs to parse the path name in the link, which always requires reading additional inodes and generally requires reading other, and potentially many, directories, processing both the list of files and the inodes of each of them until it finds a match with the link's path components. Only when a link points to a file in the same directory do "fast symlinks" provide significantly better performance than other symlinks.

The vast majority of POSIX-compliant implementations use fast symlinks. However, the [[POSIX]] standard does not require the entire set of file status information common to regular files to be implemented for symlinks. This allows implementations to use other solutions, such as storing symlink data in directory entries.

The [[file system permissions]] of a symbolic link are not used; the access modes of the target file are controlled by the target file's own permissions.  Some operating systems, such as FreeBSD, offer the ability to modify file permissions and filesystem attributes of a symbolic link, through <code>lchmod</code><ref>{{cite web |url=https://www.freebsd.org/cgi/man.cgi?query=lchmod&apropos=0&sektion=2&manpath=FreeBSD+11.0-RELEASE&arch=default&format=html |series=Manual pages for FreeBSD 11 |title=lchmod(2)}}</ref> and <code>lchflags</code><ref>{{cite web |url=https://www.freebsd.org/cgi/man.cgi?query=lchflags&apropos=0&sektion=2&manpath=FreeBSD+11.0-RELEASE&arch=default&format=html |series=Manual pages for FreeBSD 11 |title=lchflags(2)}}</ref> system calls respectively.

The reported size of a symlink is the number of characters in the path it points to.

===Error handling===
A traditional [[Unix filesystem]] has a tree structure,<ref name="Ritchie">{{cite journal |last1=Ritchie |first1=D.M. |author-link1=Dennis Ritchie |last2=Thompson  |first2=K. |author-link2=Ken Thompson |title=The UNIX Time-Sharing System |journal=Bell System Tech. J. |volume=57 |issue=6 |pages=1905–1929 |date= July 1978 |doi=10.1002/j.1538-7305.1978.tb02136.x |citeseerx=10.1.1.112.595}}</ref> however symbolic links allow it to contain loops.<ref name=":0"/> <!-- ELOOP is the current approach but I used a MicroSoft Xenix which tried to do symlink loop detection at symlink creation time as opposed  to runtime. Naturally you could create two file systems each with a non-looping symlink and then mount them to align those symlinks into a loop and hang program that tried to open them. I don't know the origin of that bug yet. I have found that there is no sign of BSD code in SCCS that has symlinks while lacking ELOOP.  Tested with: "sccsdiff -u -r4.8 -r4.9 SCCS/s.ufs_nami.c"  That leaves either the Xenix bug being written by someone at MS or something MS bought. Come to think of it, maybe BSD wasn't the first UNIX to have symlinks added to it. -->