Can you change what a symlink points to after it is created? - unix

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

Related

How to control default permission on copy file unix

I have executed a shell script in which I have copied a file as root user in another user as:
cp myFile.txt /opt/another_user/some_dir/
The file permissions in that user are -rw-r--r-- but I have the replica of this machine, where I executed the same command but the permissions of file are -rwxr-x---.
Why this default permission is different in 2 machines. Whether we set some rules while creating the user.
To ellaborate a bit on John3136's answer:
There's this thing called "file mode creation mask." Each shell has its own (ie. if you change it and open a new terminal, the new terminal gets the default value), and it's a chmod-type permission string which is subtracted from new files.
You can print yours by running umask:
$ umask
002
$ umask -S
u=rwx,g=rwx,o=rx
As you can see, mine subtracts the "other write" bit:
$ chmod 777 tmp
$ cp tmp tmp2
$ ls -l tmp2
-rwxrwxr-x 1 ahhrk ahhrk 0 may 19 10:55 tmp2*
Here's umask's generic POSIX documentation. Note that your implementation might unlikely be slightly different. On Ubuntu, I found my specific umask documentation in man 1 bash, not man umask. (The latter leads to man 2 umask, which refers to the umask() system call, which has little to do with our purposes.)
Slightly more ellaborate example:
$ # remove read from user, write from group and execute from other
$ umask 421
$ cp tmp tmp3
$ ls -l tmp3
--wxr-xrw- 1 ahhrk ahhrk 0 may 19 11:03 tmp3*
So maybe one of your file mode creation masks is removing the execute bits.
RTFM. Specically the umask FM, via man umask
You may also want to check what your chosen shell's manual page says about umask.

unix list files with a full stop in name

I have 4 files: the naming convention is as follows:
hello.account.sub1.001
hello.account.sub2.001
hello.account.sub3.001
hello.account.sub4.001
If I use ls -l hello.account*001 to search files, no problem exists.
However, problem exists when using ls -l hello.account.*.001
The system complains that No such file or directory
I assume the system considers hello.account.*.001 is a single file.
This interests me so I ask: how can you search the file if a full stop is specified as searching criteria?
Many Thanks
Filename globbing is done by the shell, before actually executing the command (such as ls in your case). The following works:
$ ksh --version
version sh (AT&T Research) 93t+ 2010-06-21
$ ls -l hello.account.*.001
-rw-r--r-- 1 andreas users 0 Jul 22 03:59 hello.account.sub1.001
-rw-r--r-- 1 andreas users 0 Jul 22 03:59 hello.account.sub2.001
-rw-r--r-- 1 andreas users 0 Jul 22 03:59 hello.account.sub3.001
-rw-r--r-- 1 andreas users 0 Jul 22 03:59 hello.account.sub4.001
while the following does not:
$ ls -l "hello.account.*.001"
ls: hello.account.*.001: No such file or directory
The reason is that in the first case, the shell expands the file name pattern before executing ls - ls will then see four different file names passed as arguments.
In the second case, since the file name pattern is escaped with double quotes, ls gets the pattern itself passed (which ls does not further expand - it looks for a file with the name hello.account.*.001)

issue with deleting unix file

Can someone please help me with this:
As seen below I have a file and directory with the same name as "sp"
How do I delete the file "sp" the one with 44673Bytes size
opxnyd#opxzone1d:/opt/opxnyd/packages/OPXPNY3DB/src/OPXPNYP>ls -alrt
-rwxr-xr-x 1 opxnyd opics 44673 Sep 7 2011 sp
drwxr-xr-x 4 opxnyd opics 1974 May 10 10:22 sp
The trick is that they don't actually have the same name. one of them has a blank or non-printing character in the name. Try ls --escape to see.
Like Charlie Martin said, they dont actually have the same name. But you could do a rm sp* without -r option (directory), deleting only the file.
Try renaming the file (any of them, then) delete the one you don't want (and rename again, if you happed to rename the folder)
You cannot have a directory and file with the same name. One of them would be probably having a white-space or some other non printable character in it.
Take this example:
$ touch "sp"
$ mkdir "sp "
$ ls -lrt
total 2
-rw-r--r-- 1 user staff 0 May 18 15:47 sp
drwxr-xr-x 2 user staff 68 May 18 15:47 sp
To delete just the file you can use following find command:
find -E . -depth 1 -type f -regex "\./sp[ \t]*" -exec rm {} \;
OR following rm command:
\rm -i sp\ *

UNIX: symlink in directories when the directory is created and when is not

See:
mkdir sym
cd sym
mkdir one
//Create the symlink
ln -s one two
ls -l
drwxr-xr-x 2 lola lola 4096 2012-02-14 07:58 one
lrwxrwxrwx 1 lola lola 3 2012-02-14 07:58 two -> one
Now, if I put something in one I could reach it in two. For what I understand two is the name of the symlink, and creates a directory to it (namely, two) [is this correct?].
Question: Is two is a directory that points to one?
But if I do:
(assuming a clean configuration)
mkdir sym
cd sym
mkdir one
mkdir two <--- notice the creation of two!!
//Create the symlink
ln -s one two
drwxr-xr-x 2 lola lola 4096 2012-02-14 07:59 one
lrwxrwxrwx 1 lola lola 3 2012-02-14 07:59 two
but in two/
lrwxrwxrwx 1 lola lola 3 2012-02-14 07:59 one -> one
If I put something in one I cannot reach it in two.
But from man ln:
SYNOPSIS
ln [OPTION]... [-T] TARGET LINK_NAME (1st form)
ln [OPTION]... TARGET (2nd form)
ln [OPTION]... TARGET... DIRECTORY (3rd form)
ln [OPTION]... -t DIRECTORY TARGET... (4th form)
I'm trying to do the 3rd form, that is: create a symlink from one directory to another directory.
Could you give me a hint about my mistake? I think is conceptual (and technical).
In your first example, "two" is not a directory. It is a simlink (basically a small label that says "if someone asks for me, look in "one" in stead.
In the second case, you indeed use the 3rd form. However what this form does is "Make a simlink to TARGET inside directory DIRECTORY. Because "two" is a directory, the ln command recognizes the second example as the 3rd form.
A symbolic link is a kind of file. It is not a directory. The readlink() system call reads the characters in the symbolic link file. That is where the "-> one" comes from in the ls display.
In order for your example to work ls -l two should show "../one" because the two symlink is inside the one directory, so for it to correctly reference the directory is has to go "up" to find one.

Unix softlinks and paths

I am somewhat confused how soft links work in unix. See the example.
% cd /usr/local/
% ls -la
total 6
drwxr-xr-x 2 root root 512 Jan 19 15:03 .
drwxr-xr-x 41 root sys 1024 Jan 20 16:24 ..
lrwxrwxrwx 1 root root 38 Jan 19 15:03 java -> /otherDir/java/jdk1.6.0_17 **<- this is a soft link**
% cd java **<- move to the softlink**
% pwd
/usr/local/java **<- the current location, say LOCATION_A**
% cd /otherDir/java/jdk1.6.0_17/ **<-move to the location of the softlink**
% pwd
/otherDir/java/jdk1.6.0_17 **<- the new current location, say LOCATION_B**
Isn't this problematic that even though LOCATION_A is LOCATION_B, they have different paths?
Is there a command (other than pwd) that will give the real location of a file (not just how the user go there).
It seems to me like pwd is just the sum of a user's cd. NOT their current location.
Try pwd -P. It's not "other than pwd" but it does the trick, at least on my bash 4.0.35 on Fedora 12. YMMV.
Update: Even works with sh, so it seems to be portable.
This behaves like this with a purpose. If you cd to /a/b/c/d and then cd to .. then you realistically expect to be in /a/b/c. If c happens to be a symbolic link (or symlink in unix terms - but not soft link) that takes you to /f/g/h, with the behaviour you would like to have you would end up in /f/g and then you (or any program) would not understand how it got there.
You can use readlink on the current working directory to get the true directory name:
readlink `pwd`
Normally, pwd should return /usr/local/java in the last line, if i understand your example. But some shells have a build in pwd command that tries to be more "intelligent" handling symlinks in the current working directory.
Try /bin/pwd, do you get other results?
realpath does what you want.
It is not possible to absolutely get your path under all circumstances. This is a bit odd, but a variation of this (plus chroot and setuid) is sometimes used for locking down a process.
$ mkdir -p /tmp/a/b
$ cd /tmp/a/b
$ rmdir /tmp/a/b
$ chmod 0 /tmp/a
$ rmdir /tmp/a
$ ls ..
ls: cannot open directory ..: Permission denied
$ ls -al
total 0
$ pwd -P
pwd: error retrieving current directory: getcwd: cannot access parent directories: No such file or directory

Resources