`ln -s` in a script acts as `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, a hard copy (=cp) is performed and config.properties is often not a symbolic link (nor a physical link for that matter) 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 in the prompt manually line by line, I have no trouble and a symbolic link is indeed always created and config.properties points towards 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

• No file is open anywhere else (I'm the only active user and the application using the configuration isn't running).
• Sometimes ln -sf acts normally, but the usual rule is that it makes a hard copy.
• The script is run from another directory, but cds to the directory where the config*.properties files are located before performing the actions here.
• The script is way much longer, but this is the shortest example that reproduces the error.
• bash version is 4.1.2 (it's local, so I don't care about shellshock).
• ln version is 8.4.
• Operating System: Red Hat Enterprise Linux Server release 6.5 (Santiago).
• Filesystem used for that folder: ext4.

Question

• Why doesn't my script consistently create a symbolic link but makes a hard copy?
• How to force a symbolic link here?

Answer 1

I suspect you have some other script or code that is overwriting the symlinks. For example, sed -i will trash symlinks. There are a variety of commands and utilities that modify a file by creating a copy, modifying the copy, and then moving the copy over top of the original, which destroys the original symlink.

Answer 2

The only answer possible to the question (as asked): why ln behave as cp is: It can not.

The only other possible answer is: what you present to us is not exactly what is being executed, or there are other scripts running which alter the answer.

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

2.- Is there an alias or function for ln?
That is easy to check. Just issue type -a ln inside Bash. The result will show what is bash interpreting ln to be. If it is ONLY the file /bin/ln, then it is correct.
You confirmed that there is no alias or function involved.

3.- As "the script is run from another directory". The point here is: Is there other file anywhere in the filesystem that has the same i-node number (if ln is actually creating a hard link). The existence of some other file with the same i-node could be verified with (use the inode numbers 53,54,56 from your listing):

find / -follow -inum <your inum>

4.- I hope that you are truly aware that config-b.properties does not actually exist (as a file). Editing such file may trash the link.

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

Note01: Note that the K trick does resolve the extraction in just one external call: http://www.charlestonsw.com/perl-regular-expression-k-trick/

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

It has been confirmed that a sed -i to config-b.properties later in the real executed script was the source of the problem.