lnCreate hard links and symbolic links
ln gives a file another name. A hard link is a second name for the same inode; a symbolic link (-s) is a tiny file that stores a path. Symlinks are everywhere in operations: 'current' release folders, sites-enabled in nginx, /etc/alternatives, and versioned binaries.
ln [OPTION]... TARGET LINK_NAME ln -s TARGET LINK_NAMEYou want a short, stable name for a file that lives deep in a directory tree.
sudoRoot is needed because the link is created in /opt/app, a root-owned directory.
A directory entry is just a name pointing to an inode number. A hard link (ln with no -s) calls link(), which adds a second entry pointing to the same inode and increments its link count; both names are equal, there is no 'original'. The data survives until the link count reaches 0 and no process has the file open. Because inode numbers are only unique within one filesystem, hard links can't cross filesystems (EXDEV), and they aren't allowed on directories to keep the tree free of loops. A symbolic link (ln -s) calls symlink(), which creates a new inode of type link whose content is the target path, stored as text and not checked at creation. Every time a program opens the symlink, the kernel reads that text and resolves it, relative to the link's own directory if it doesn't start with /. So symlinks can point across filesystems and to directories, and they break (dangle) when the target is moved or deleted. ln -sf replaces a link by unlinking and recreating it, which is not atomic.
A hard link is another name for the same inode; a symlink is a separate file that stores a path and is resolved by name.
The directory entry app.yaml holds an inode number. The inode holds owner, mode, size, the link count and where the data blocks are.
-sCreate a symbolic link instead of a hard link-fRemove an existing destination first-nTreat a symlink-to-directory LINK_NAME as a file (replace it)-TAlways treat LINK_NAME as a file name, never a directory-rMake the symlink's target relative to the link's location-vPrint each link created-iAsk before replacing an existing destinationreadlink -f LINKShow the fully resolved target of a linkln -s current releases/v42 (arguments swapped)ln takes TARGET first and the new LINK_NAME second, like cp. Swapped, you create a link named v42 inside releases pointing at 'current'.
ln -s releases/v42 current (think: ln -s WHAT WHERE)ln -sf releases/v42 current when current links to a directoryln follows the existing link and creates releases/v41/v42 inside the old release; current doesn't change.
ln -sfn releases/v42 current (or ln -s ... tmp && mv -T tmp current for an atomic switch)ln -s app.yaml /etc/app/app.yaml from inside your project directoryA relative target is resolved from the link's directory (/etc/app), not from where you ran ln, so the link dangles.
ln -s "$PWD/app.yaml" /etc/app/app.yaml or ln -srchmod 600 on a symlink to protect the targetSymlink permissions are always rwxrwxrwx and ignored; chmod on a link changes the target's mode.
Set permissions on the target file itselfTry these on a Linux machine of your own. Each task has a hint and a solution.
Create a symlink ~/conf pointing at /etc/app/app.conf, and read the config through it.
Make a hard link ~/data/orders-link.csv to ~/data/orders.csv and prove both names share one inode.
Find the broken symlink in ~/app and see what it points to.
Create ~/rel/v1 and ~/rel/v2, point ~/rel/current at v1, then switch it to v2 correctly.
lnCreate hard links and symbolic links
ln gives a file another name. A hard link is a second name for the same inode; a symbolic link (-s) is a tiny file that stores a path. Symlinks are everywhere in operations: 'current' release folders, sites-enabled in nginx, /etc/alternatives, and versioned binaries.
ln [OPTION]... TARGET LINK_NAME ln -s TARGET LINK_NAMEYou want a short, stable name for a file that lives deep in a directory tree.
sudoRoot is needed because the link is created in /opt/app, a root-owned directory.
A directory entry is just a name pointing to an inode number. A hard link (ln with no -s) calls link(), which adds a second entry pointing to the same inode and increments its link count; both names are equal, there is no 'original'. The data survives until the link count reaches 0 and no process has the file open. Because inode numbers are only unique within one filesystem, hard links can't cross filesystems (EXDEV), and they aren't allowed on directories to keep the tree free of loops. A symbolic link (ln -s) calls symlink(), which creates a new inode of type link whose content is the target path, stored as text and not checked at creation. Every time a program opens the symlink, the kernel reads that text and resolves it, relative to the link's own directory if it doesn't start with /. So symlinks can point across filesystems and to directories, and they break (dangle) when the target is moved or deleted. ln -sf replaces a link by unlinking and recreating it, which is not atomic.
A hard link is another name for the same inode; a symlink is a separate file that stores a path and is resolved by name.
The directory entry app.yaml holds an inode number. The inode holds owner, mode, size, the link count and where the data blocks are.
-sCreate a symbolic link instead of a hard link-fRemove an existing destination first-nTreat a symlink-to-directory LINK_NAME as a file (replace it)-TAlways treat LINK_NAME as a file name, never a directory-rMake the symlink's target relative to the link's location-vPrint each link created-iAsk before replacing an existing destinationreadlink -f LINKShow the fully resolved target of a linkln -s current releases/v42 (arguments swapped)ln takes TARGET first and the new LINK_NAME second, like cp. Swapped, you create a link named v42 inside releases pointing at 'current'.
ln -s releases/v42 current (think: ln -s WHAT WHERE)ln -sf releases/v42 current when current links to a directoryln follows the existing link and creates releases/v41/v42 inside the old release; current doesn't change.
ln -sfn releases/v42 current (or ln -s ... tmp && mv -T tmp current for an atomic switch)ln -s app.yaml /etc/app/app.yaml from inside your project directoryA relative target is resolved from the link's directory (/etc/app), not from where you ran ln, so the link dangles.
ln -s "$PWD/app.yaml" /etc/app/app.yaml or ln -srchmod 600 on a symlink to protect the targetSymlink permissions are always rwxrwxrwx and ignored; chmod on a link changes the target's mode.
Set permissions on the target file itselfTry these on a Linux machine of your own. Each task has a hint and a solution.
Create a symlink ~/conf pointing at /etc/app/app.conf, and read the config through it.
Make a hard link ~/data/orders-link.csv to ~/data/orders.csv and prove both names share one inode.
Find the broken symlink in ~/app and see what it points to.
Create ~/rel/v1 and ~/rel/v2, point ~/rel/current at v1, then switch it to v2 correctly.