The `ln -s` in the script acts like a` cp`

Question

Problem

I have this bash script:

ACTIVE_DB=$(grep -P "^[ \t]*db.active" config.properties | cut -d= -f2 | tr -s " ") echo $ACTIVE_DB if [ "$ACTIVE_DB" = "A" ] then ln -sf config-b.properties config.properties else ln -sf config-a.properties config.properties fi 

config-a.properties

 db.active = A 

config-b.properties

 db.active = B 

When I run the script, the hard copy (= cp ) is executed, and config.properties often not a symbolic link (and not a physical link), but a whole new file with the same content as config-a.properties or config-b.properties .

 $ ls -li 53 -rw-r--r-- 1 ogregoir ogregoir 582 Sep 30 15:41 config-a.properties 54 -rw-r--r-- 1 ogregoir ogregoir 582 Sep 30 15:41 config-b.properties 56 -rw-r--r-- 1 ogregoir ogregoir 582 Oct 2 11:28 config.properties 

When I run this on a line manually, line by line, I have no problem, and a symlink is always created, and config.properties points to config-a.properties or config-b.properties .

 $ ls -li 53 -rw-r--r-- 1 ogregoir ogregoir 582 Sep 30 15:41 config-a.properties 54 -rw-r--r-- 1 ogregoir ogregoir 582 Sep 30 15:41 config-b.properties 55 lrwxrwxrwx 1 ogregoir ogregoir 20 Oct 2 11:41 config.properties -> config-b.properties 

Notes

• The file is not opened anywhere (I am the only active user, and the application using the configuration does not work).
• Sometimes ln -sf works fine, but the usual rule is that it makes a hard copy.
• The script is run from another directory, but cd to the directory where the config*.properties files are located before doing the actions here.
• The script is much longer, but this is the shortest example that reproduces the error.
• bash version 4.1.2 (it’s local, so I don’t need shellshock).
• ln version is 8.4.
• Operating System: Red Hat Enterprise Linux Server 6.5 (Santiago).
• The file system used for this folder is ext4.

Question

• Why is my script sequentially creating a symlink but making a hard copy?
• How to force a symbolic link here?

Answer 1

I suspect you have another script or code that rewrites symbolic links. For example, sed -i destroy symbolic links. There are many commands and utilities that modify the file, create a copy, modify the copy, and then move the copy over the original, which destroys the original symbolic link.

Answer 2

The only answer to the question (on assignment): why ln behaves like cp is: It can not.

The only possible answer: what you present to us is not quite what is being executed, or there are other scripts that change the answer.

Some possible alternatives are:
1.- The ln command actually executes a hard link. The i-node list ( ls -li ) confirms that the i-node numbers are different. So no, that’s not the reason.

2.- Is there an alias or function for ln ?
This is easy to verify. Just type type -a ln inside Bash. As a result, it will be shown that bash will interpret ln . If this is ONLY the /bin/ln file, then this is correct.
You have confirmed that there is no alias or function.

3.- Like "the script is launched from another directory". The point here is: is there another file in the file system that has the same i-node number (if ln actually creates a hard link). The existence of any other file with the same i-node can be checked with (use inode numbers 53.54.56 from your list):

 find / -follow -inum <your inum> 

4.- I hope you really know that config-b.properties does not actually exist (as a file). Editing such a file may delete the link.

Is the actual script also changing / updating the contents of the file?

Note01: Note that trick K only allows one external call to be retrieved: http://www.charlestonsw.com/perl-regular-expression-k-trick/

 ACTIVE_DB=$(grep -Po "^[ \t]*db.active[ ]+=[ ]+\K." config.properties) 

It was confirmed that the source config-b.properties later in the actual executed script was sed -i to config-b.properties .