Bug 742319 - test -f returns true for symlinks pointing to regular files
test -f returns true for symlinks pointing to regular files
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: coreutils (Show other bugs)
16
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Ondrej Vasik
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2011-09-29 12:54 EDT by Jerry Amundson
Modified: 2012-07-16 07:41 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-07-16 07:41:23 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Jerry Amundson 2011-09-29 12:54:21 EDT
Description of problem:
test -f return true for symlinks

Version-Release number of selected component (if applicable):
coreutils-8.12-2.fc16.src.rpm

How reproducible:
always

Steps to Reproduce:
1.With xen installed,  for F in /boot/xen*; do if /usr/bin/test -f ${F}; then echo ${F} is a file.; fi; done
2.
3.
  
Actual results:
/boot/xen-4.1.1.gz is a file.
/boot/xen-4.1.gz is a file.
/boot/xen.gz is a file.
/boot/xen-syms-4.1.1 is a file.

Expected results:
/boot/xen-4.1.1.gz is a file.
/boot/xen-syms-4.1.1 is a file.

Additional info:
# ll /boot/xen*
-rw-r--r--. 1 root root   729540 Aug 14 09:29 /boot/xen-4.1.1.gz
lrwxrwxrwx. 1 root root       12 Sep 19 12:57 /boot/xen-4.1.gz -> xen-4.1.1.gz
lrwxrwxrwx. 1 root root       12 Sep 19 12:57 /boot/xen.gz -> xen-4.1.1.gz
-rw-r--r--. 1 root root 12958461 Aug 14 09:29 /boot/xen-syms-4.1.1

This prevents, for example, grub2-mkconfig from working properly - it uses the two symlinks and creates extra boot menus.
Comment 1 Jerry Amundson 2011-09-29 13:31:06 EDT
This is a regression from coreutils-5.x.
Comment 2 Ondrej Vasik 2011-09-29 13:40:18 EDT
Well, I think this is not a bug but expected behaviour - if the symlink points to regular file, it is dereferenced and recognized as regular file by test -f (or shell builtin -f ) ...
However, if the symlink is broken, it is not recognized as regular file.
Check:
[Reset@dhcp-24-196 ~]$ ln -s broken brokenlink
[Reset@dhcp-24-196 ~]$ test -f brokenlink && echo is file

In Debian, similar bugzilla was wontfixed see e.g. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=231267 ... 

However, there is one argument for improving manpage/info documentation - find behaves differently in that case...
[Reset@dhcp-24-196 ~]$ find /lib -name libz.so.1 -type f
[Reset@dhcp-24-196 ~]$ find /lib -name libz.so.1
/lib/libz.so.1
[Reset@dhcp-24-196 ~]$ test -f /lib/libz.so.1 && echo is file
is file
[Reset@dhcp-24-196 ~]$ /usr/bin/test -f /lib/libz.so.1 && echo is file
is file

Leaving it opened for a while (upstream is on bugzilla watch) ...
Comment 3 Ondrej Vasik 2011-09-29 13:51:52 EDT
POSIX ( http://pubs.opengroup.org/onlinepubs/000095399/utilities/test.html ) states :

-f  pathname
    True if pathname resolves to a file that exists and is a regular file. False if pathname cannot be resolved, or if pathname resolves to a file that exists but is not a regular file.

So it is all about definition of "pathname resolving" ...
Comment 4 Jerry Amundson 2011-09-29 16:46:50 EDT
(In reply to comment #1)
> This is a regression from coreutils-5.x.

For the record, that is untrue. My mistake, sorry.
Comment 5 Ondrej Vasik 2012-07-16 07:41:23 EDT
Cleanup ... closing NOTABUG based on comment #3.

Note You need to log in before you can comment on or make changes to this bug.