I'm not sure if this is possible. I've been fiddling with a MWE for awhile.
I'm using rsync in relative mode (-R) to copy a remote directory from a server onto my local machine. The remote directory may have symlinks. Sometimes the symlinks point within the scope of the relative directory, and sometimes they point outside of it.
When the links point inside the relative directory, I want to only copy the links (because the files are already synced, so those links should resolve).
When the links point outside the relative directory, I want to copy the files themselves because otherwise the links would likely not resolve.
I've setup a MWE to test various ways of doing this:
TEST_BASE=rsync_test
REMOTE_DPATH=$HOME/tmp/rsync-test/remote
LOCAL_DPATH=$HOME/tmp/rsync-test/local
REMOTE_URI=$REMOTE_DPATH
REMOTE_MOUNT=$REMOTE_DPATH
reset_rsync_test_remote()
{
# Clean
if [ -d "$REMOTE_DPATH" ]; then
rm -rf $REMOTE_DPATH
fi
mkdir -p $REMOTE_DPATH
# Setup remote data
mkdir -p $REMOTE_DPATH/$TEST_BASE/root/dir_L0_X0_A
mkdir -p $REMOTE_DPATH/$TEST_BASE/root/dir_L0_X0_A/dir_L1_X0_B
mkdir -p $REMOTE_DPATH/$TEST_BASE/root/dir_L0_X1_C
mkdir -p $REMOTE_DPATH/$TEST_BASE/root/inside_dir
mkdir -p $REMOTE_DPATH/$TEST_BASE/root/links
mkdir -p $REMOTE_DPATH/$TEST_BASE/outside_dir/
touch $REMOTE_DPATH/$TEST_BASE/root/file_L0_X0_a.txt
touch $REMOTE_DPATH/$TEST_BASE/root/dir_L0_X0_A/file_L1_X0_b.txt
touch $REMOTE_DPATH/$TEST_BASE/root/dir_L0_X1_C/file_L1_X0_c.txt
touch $REMOTE_DPATH/$TEST_BASE/root/inside_dir/inside_file.txt
touch $REMOTE_DPATH/$TEST_BASE/outside_dir/outside_file.txt
# Create links to inside and outside the sync root
ln -s $REMOTE_DPATH/$TEST_BASE/root/inside_dir/inside_file.txt $REMOTE_DPATH/$TEST_BASE/root/links/inside_flink.txt
ln -s $REMOTE_DPATH/$TEST_BASE/outside_dir/outside_file.txt $REMOTE_DPATH/$TEST_BASE/root/links/outside_flink.txt
ln -s $REMOTE_DPATH/$TEST_BASE/outside_dir $REMOTE_DPATH/$TEST_BASE/root/links/outside_dlink
ln -s $REMOTE_DPATH/$TEST_BASE/root/inside_dir $REMOTE_DPATH/$TEST_BASE/root/links/inside_dlink
ln -sr $REMOTE_DPATH/$TEST_BASE/root/inside_dir/inside_file.txt $REMOTE_DPATH/$TEST_BASE/root/links/rel_inside_flink.txt
ln -sr $REMOTE_DPATH/$TEST_BASE/outside_dir/outside_file.txt $REMOTE_DPATH/$TEST_BASE/root/links/rel_outside_flink.txt
ln -sr $REMOTE_DPATH/$TEST_BASE/outside_dir $REMOTE_DPATH/$TEST_BASE/root/links/rel_outside_dlink
ln -sr $REMOTE_DPATH/$TEST_BASE/root/inside_dir $REMOTE_DPATH/$TEST_BASE/root/links/rel_inside_dlink
tree $REMOTE_DPATH/
}
reset_rsync_test_local(){
# Setup home data
echo "LOCAL_DPATH = $LOCAL_DPATH"
if [ -d "$LOCAL_DPATH" ]; then
rm -rf $LOCAL_DPATH
fi
mkdir -p $LOCAL_DPATH
mkdir -p $LOCAL_DPATH/$TEST_BASE
# Make an existing link on the destination that we will sync to
mkdir -p $LOCAL_DPATH/link-dest1
mkdir -p $LOCAL_DPATH/link-dest2
ln -s $LOCAL_DPATH/link-dest1 $LOCAL_DPATH/rsync_test-link
ln -s $LOCAL_DPATH/link-dest2 $LOCAL_DPATH/rsync_test-link/root
tree $LOCAL_DPATH
}
reset_rsync_test_remote
This will setup my fake "remote" directory, which looks like this:
The relative directory that we are going to sync is "root".
Notice the links on the bottom. Some of them point inside "root" (in which case they are have inside_ in their name) and some point outside of "root", (in which case they have outside_ in their name). Then half of them are absolute links and the other half are relative links (rel_ prefix). This enumerates all 8 possibilities I'm concerned with here.
I'm going to rsync the "root" directory to an existing symlink within a symlink on my "local" machine to simulate my normal use case. This shouldn't matter too much, it just means we have to specify (-K) when running rsync.
So far I have two methods for doing roughly what I want to do but each has flaws. In the first method I use (-L), which simply resolves all links to their hard files.
# Method 1 with -KL
# The -K is important when syncing to a destination dir that is a symlink
# The -L will resolve any symlinks
# this grabs everything however, all files will be copied over as hard files
reset_rsync_test_local
rsync -avPRKL $REMOTE_URI/$TEST_BASE/./root $LOCAL_DPATH/rsync_test-link
ls -al $LOCAL_DPATH/
ls -al $LOCAL_DPATH/rsync_test-link/
tree $LOCAL_DPATH/link-dest2
Method 2 gets closer, in that it at least links the rel_inside_flink but doesn't link the rel_inside_dlink and it fails to resolve the rel_outside_dlink.
# Method 2: with -Kk --copy-unsafe-links
# Alternatively using -k --copy-unsafe-links will get almost everything
# links inside the relative directory are copied as links, links outside
# the relative dir are copied as files, except relative outside files for
# whatever reason.
reset_rsync_test_local
rsync -avPRKk --copy-unsafe-links $REMOTE_URI/$TEST_BASE/./root $LOCAL_DPATH/rsync_test-link
ls -al $LOCAL_DPATH/
ls -al $LOCAL_DPATH/rsync_test-link/
tree $LOCAL_DPATH/link-dest2
What I'd like is information on how to accomplish either of the following:
In the better than what I have case:
What I'd like is for any rel_inside link would be copied directly as a link, while all other links were resolved and copied as files.
In the absolutely ideal case: it would convert the absolute links that point inside the relative directory to either relative or absolute links at the destination (e.g. inside_dlink would either convert itself to ../inside_dir or /home/joncrall/tmp/rsync-test/local/rsync_test/root/inside_dir).
e.g. from the Mac man pages:
man ln
-h If the NewLinkFile (or directory) is a symbolic link, do not follow
it. This is most useful with the -f option, to replace a symlink
which can point to a directory.
I am writing a script which once a day iterates over hundreds of files and symlinks them all and then periodically through out the day checks for new files and symlinks them. Would be great to use this -h check or something similar as at the moment it is done very awkwardly.
A GNU equivalent of the BSD ln -sh is ln -sn.
But GNU's ln -sT is safer, because it will skip both symbolic links and directories.
Compare:
cd "$(mktemp -d)"
mkdir bin
for d in bin usr etc; do ln -sn "/$d" "$d"; done
# will create a bin/bin -> /bin symlink
vs.
cd "$(mktemp -d)"
mkdir bin
for d in bin usr etc; do ln -sT "/$d" "$d"; done
ln: failed to create symbolic link 'bin': File exists
How to extract the ports, src, sys trees to /user/ports, /usr/src, usr/src/sys in OpenBSD. Command to do the download and the untar.
Check the PortsFetch section of the faq:
Once you have decided which flavor of the ports tree you want, you can get it from different sources. The table below gives an overview of where you can find the different flavors, and in which form. An 'o' marks availability and '-' means it is not available through that specific source.
Look for a file named ports.tar.gz on the mirrors.
$ cd /tmp
$ ftp https://ftp.openbsd.org/pub/OpenBSD/$(uname -r)/{ports.tar.gz,SHA256.sig}
$ signify -Cp /etc/signify/openbsd-$(uname -r | cut -c 1,3)-base.pub -x SHA256.sig ports.tar.gz
You want to untar this file in the /usr directory, which will create /usr/ports and all the directories under it.
# cd /usr
# tar xzf /tmp/ports.tar.gz
I have a list of dotFiles at my workarea. For example, .bashrc and .vimrc.
I want to make a symlinks from them to my Home such that their names are the same as in my workarea -folder.
My attempt in pseudo-code
ln workarea/.[a-zA-Z] ~/.*
The problem is to have a bijection from [a-zA-Z] to the files which occur in my Home.
How can you make symlinks with the target files of same name as the original files?
'man ln' says:
ln [OPTION]... TARGET... DIRECTORY (3rd form)
So you need to do something like:
$ ln -s workarea/.* ~/
The possible uses of ln to create symbolic link(s) are:
ln -s <source-file> [<target-file]>
ln -s <source-file> ... <target-dir>
When you type
ln -s workarea/.[a-zA-Z]* ~/.*
(I think you were missing a *) the shell will expand out workarea/.[a-zA-Z] and ~/.*, so (presuming that the your HOME directory contains the files .abc and .def) you would end up with
ln -s workarea/.bash_profile workarea/.bashrc ~/.abc ~/.def
which fits neither usage of ln.
To use the second usage of ln, you would use:
ln -s workarea/.[a-zA-Z]* ~/.
Does any operating system provide a mechanism (system call — not command line program) to change the pathname referenced by a symbolic link (symlink) — other than by unlinking the old one and creating a new one?
The POSIX standard does not. Solaris 10 does not. MacOS X 10.5 (Leopard) does not. (I'm tolerably certain neither AIX nor HP-UX does either. Judging from this list of Linux system calls, Linux does not have such a system call either.)
Is there anything that does?
(I'm expecting that the answer is "No".)
Since proving a negative is hard, let's reorganize the question.
If you know that some (Unix-like) operating system not already listed has no system call for rewriting the value of a symlink (the string returned by readlink()) without removing the old symlink and creating a new one, please add it — or them — in an answer.
Yes, you can!
$ ln -sfn source_file_or_directory_name softlink_name
AFAIK, no, you can't. You have to remove it and recreate it. Actually, you can overwrite a symlink and thus update the pathname referenced by it:
$ ln -s .bashrc test
$ ls -al test
lrwxrwxrwx 1 pascal pascal 7 2009-09-23 17:12 test -> .bashrc
$ ln -s .profile test
ln: creating symbolic link `test': File exists
$ ln -s -f .profile test
$ ls -al test
lrwxrwxrwx 1 pascal pascal 8 2009-09-23 17:12 test -> .profile
EDIT: As the OP pointed out in a comment, using the --force option will make ln perform a system call to unlink() before symlink(). Below, the output of strace on my linux box proving it:
$ strace -o /tmp/output.txt ln -s -f .bash_aliases test
$ grep -C3 ^unlink /tmp/output.txt
lstat64("test", {st_mode=S_IFLNK|0777, st_size=7, ...}) = 0
stat64(".bash_aliases", {st_mode=S_IFREG|0644, st_size=2043, ...}) = 0
symlink(".bash_aliases", "test") = -1 EEXIST (File exists)
unlink("test") = 0
symlink(".bash_aliases", "test") = 0
close(0) = 0
close(1) = 0
So I guess the final answer is "no".
EDIT: The following is copied from Arto Bendiken's answer over on unix.stackexchange.com, circa 2016.
This can indeed be done atomically with rename(2), by first creating the new symlink under a temporary name and then cleanly overwriting the old symlink in one go. As the man page states:
If newpath refers to a symbolic link the link will be overwritten.
In the shell, you would do this with mv -T as follows:
$ mkdir a b
$ ln -s a z
$ ln -s b z.new
$ mv -T z.new z
You can strace that last command to make sure it is indeed using rename(2) under the hood:
$ strace mv -T z.new z
lstat64("z.new", {st_mode=S_IFLNK|0777, st_size=1, ...}) = 0
lstat64("z", {st_mode=S_IFLNK|0777, st_size=1, ...}) = 0
rename("z.new", "z") = 0
Note that in the above, both mv -T and strace are Linux-specific.
On FreeBSD, use mv -h alternately.
Editor's note: This is how Capistrano has done it for years now, ever since ~2.15. See this pull request.
It is not necessary to explicitly unlink the old symlink. You can do this:
ln -s newtarget temp
mv temp mylink
(or use the equivalent symlink and rename calls). This is better than explicitly unlinking because rename is atomic, so you can be assured that the link will always point to either the old or new target. However this will not reuse the original inode.
On some filesystems, the target of the symlink is stored in the inode itself (in place of the block list) if it is short enough; this is determined at the time it is created.
Regarding the assertion that the actual owner and group are immaterial, symlink(7) on Linux says that there is a case where it is significant:
The owner and group of an existing symbolic link can be changed using
lchown(2). The only time that the ownership of a symbolic link matters is
when the link is being removed or renamed in a directory that has the sticky
bit set (see stat(2)).
The last access and last modification timestamps of a symbolic link can be
changed using utimensat(2) or lutimes(3).
On Linux, the permissions of a symbolic link are not used in any operations;
the permissions are always 0777 (read, write, and execute for all user
categories), and can't be changed.
Just a warning to the correct answers above:
Using the -f / --force Method provides a risk to lose the file if you mix up source and target:
mbucher#server2:~/test$ ls -la
total 11448
drwxr-xr-x 2 mbucher www-data 4096 May 25 15:27 .
drwxr-xr-x 18 mbucher www-data 4096 May 25 15:13 ..
-rw-r--r-- 1 mbucher www-data 4109466 May 25 15:26 data.tar.gz
-rw-r--r-- 1 mbucher www-data 7582480 May 25 15:27 otherdata.tar.gz
lrwxrwxrwx 1 mbucher www-data 11 May 25 15:26 thesymlink -> data.tar.gz
mbucher#server2:~/test$
mbucher#server2:~/test$ ln -s -f thesymlink otherdata.tar.gz
mbucher#server2:~/test$
mbucher#server2:~/test$ ls -la
total 4028
drwxr-xr-x 2 mbucher www-data 4096 May 25 15:28 .
drwxr-xr-x 18 mbucher www-data 4096 May 25 15:13 ..
-rw-r--r-- 1 mbucher www-data 4109466 May 25 15:26 data.tar.gz
lrwxrwxrwx 1 mbucher www-data 10 May 25 15:28 otherdata.tar.gz -> thesymlink
lrwxrwxrwx 1 mbucher www-data 11 May 25 15:26 thesymlink -> data.tar.gz
Of course this is intended, but usually mistakes occur. So, deleting and rebuilding the symlink is a bit more work but also a bit saver:
mbucher#server2:~/test$ rm thesymlink && ln -s thesymlink otherdata.tar.gz
ln: creating symbolic link `otherdata.tar.gz': File exists
which at least keeps my file.
Wouldn't unlinking it and creating the new one do the same thing in the end anyway?
Just in case it helps: there is a way to edit a symlink with midnight commander (mc).
The menu command is (in French on my mc interface):
Fichier / Éditer le lien symbolique
which may be translated to:
File / Edit symbolic link
The shortcut is C-x C-s
Maybe it internally uses the ln --force command, I don't know.
Now, I'm trying to find a way to edit a whole lot of symlinks at once (that's how I arrived here).
Technically, there's no built-in command to edit an existing symbolic link. It can be easily achieved with a few short commands.
Here's a little bash/zsh function I wrote to update an existing symbolic link:
# -----------------------------------------
# Edit an existing symbolic link
#
# #1 = Name of symbolic link to edit
# #2 = Full destination path to update existing symlink with
# -----------------------------------------
function edit-symlink () {
if [ -z "$1" ]; then
echo "Name of symbolic link you would like to edit:"
read LINK
else
LINK="$1"
fi
LINKTMP="$LINK-tmp"
if [ -z "$2" ]; then
echo "Full destination path to update existing symlink with:"
read DEST
else
DEST="$2"
fi
ln -s $DEST $LINKTMP
rm $LINK
mv $LINKTMP $LINK
printf "Updated $LINK to point to new destination -> $DEST"
}
You can modify the softlink created once in one of the two ways as below in Linux
one is where you can remove existing softlink with rm and again create new softlink with ln -s command .
However this can be done in one step , you can replace existing softlink with updated path with "ln -vfns Source_path Destination_path" command.
Listing initial all files in directory
$ ls -lrt
drwxrwxr-x. 3 root root 110 Feb 27 18:58 test_script
$
Create softlink test for test_script with ln -s command.
$ ln -s test_script test
$ ls -lrt
drwxrwxr-x. 3 root root 110 Feb 27 18:58 test_script
lrwxrwxrwx. 1 root root 11 Feb 27 18:58 test -> test_script
$
Update softlink test with new directory test_script/softlink with single command
$ ln -vfns test_script/softlink/ test
'test' -> 'test_script/softlink/'
$
List new softlink location
$ ls -lrt
lrwxrwxrwx. 1 root root 21 Feb 27 18:59 test -> test_script/softlink/
$
ln --help
-v, --verbose print name of each linked file
-f, --force remove existing destination files
-n, --no-dereference treat LINK_NAME as a normal file if it is a symbol
-s, --symbolic make symbolic links instead of hard links