Changed "rename" behaviour with dangling symlinks
by jwoithe from LinuxQuestions.org on (#51XMZ)
I have noted changed behaviour in the "rename" command in slackware64-current when renaming dangling symlinks. If "foobar45" is a dangling symlink, it could still be renamed in Slackware64-14.2:
Code:rename foobar45 foobar foobar45However, in Slackware64-current (snapshot from yesterday), the rename command flags an error:
Code:rename: foobar45: not accessible: No such file or directoryIt seems that "rename" is now attempting to dereference the symlink, rather than simply rename it. Is this an intended change in the util-linux package shipped in Slackware64-current?
In the simplified example given above it is possible to work around the issue with "mv":
Code:mv foobar45 foobarHowever, where there are multiple files to rename things become more complex, requiring a loop. Rename is more convenient.
The offending test in rename.c appears to be line 110-111:
Code:if ( faccessat(AT_FDCWD, s, F_OK, AT_SYMLINK_NOFOLLOW) != 0 &&
errno != EINVAL )My reading of the faccessat() documentation suggests that the AT_SYMLINK_NOFOLLOW flag should stop faccessat() dereferencing a symlink, but this doesn't seem to be the case. The system was using a 5.4.30 kernel when this issue was observed.
Assuming this is the behaviour intended by upstream there is probably little we can do about it other than be aware of the change between Slackware64-14.2 and Slackware64-current (14.2+).
Code:rename foobar45 foobar foobar45However, in Slackware64-current (snapshot from yesterday), the rename command flags an error:
Code:rename: foobar45: not accessible: No such file or directoryIt seems that "rename" is now attempting to dereference the symlink, rather than simply rename it. Is this an intended change in the util-linux package shipped in Slackware64-current?
In the simplified example given above it is possible to work around the issue with "mv":
Code:mv foobar45 foobarHowever, where there are multiple files to rename things become more complex, requiring a loop. Rename is more convenient.
The offending test in rename.c appears to be line 110-111:
Code:if ( faccessat(AT_FDCWD, s, F_OK, AT_SYMLINK_NOFOLLOW) != 0 &&
errno != EINVAL )My reading of the faccessat() documentation suggests that the AT_SYMLINK_NOFOLLOW flag should stop faccessat() dereferencing a symlink, but this doesn't seem to be the case. The system was using a 5.4.30 kernel when this issue was observed.
Assuming this is the behaviour intended by upstream there is probably little we can do about it other than be aware of the change between Slackware64-14.2 and Slackware64-current (14.2+).