[bug #54667] find -type l fails to find symlink on NTFS volumes under linux

[Aaron Queenan]

URL:
  <https://savannah.gnu.org/bugs/?54667>

                 Summary: find -type l fails to find symlink on NTFS volumes
under linux
                 Project: findutils
            Submitted by: aqueenan
            Submitted on: Mon 17 Sep 2018 12:18:29 AM UTC
                Category: find
                Severity: 3 - Normal
              Item Group: Wrong result
                  Status: None
                 Privacy: Public
             Assigned to: None
         Originator Name: 
        Originator Email: 
             Open/Closed: Open
         Discussion Lock: Any
                 Release: 4.6.0
           Fixed Release: None

    _______________________________________________________

Details:

Given the following files, including a link created with ln -s on the same
system, several problems occur with symlinks on NTFS volumes.

address@hidden test]# l
-rw-rw-rw-    1 admin    administ         0 Sep 17 07:43 file
lr--r--r--    1 admin    administ        18 Sep 17 07:43 link -> file

= System =

address@hidden test]# uname -a
Linux storage 3.4.6 #1 SMP Wed Aug 29 12:08:32 CST 2018 x86_64 unknown

= find -type l behaviour =

The first problem is that –type l doesn’t find the symlink at all and
–type f includes symlinks in the result.

== GNU find ==

address@hidden test]# find --version
find (GNU findutils) 4.6.0
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Eric B. Decker, James Youngman, and Kevin Dalley.
Features enabled: D_TYPE O_NOFOLLOW(enabled) LEAF_OPTIMISATION FTS(FTS_CWDFD)
CBO(level=2) 

address@hidden test]# find . -type l

== BusyBox ==

The BusyBox version of find correctly detects the symlink.

address@hidden test]# /usr/bin/find --version
BusyBox v1.01 (2018.08.29-02:29+0000) multi-call binary

Usage: find [PATH...] [EXPRESSION]

Search for files in a directory hierarchy.  The default PATH is
the current directory; default EXPRESSION is '-print'

EXPRESSION may consist of:
        -follow         Dereference symbolic links.
        -name PATTERN   File name (leading directories removed) matches
PATTERN.
        -print          Print (default and assumed).

        -type X         Filetype matches X (where X is one of: f,d,l,b,c,...)
        -perm PERMS     Permissions match any of (+NNN); all of (-NNN);
                        or exactly (NNN)
        -mtime TIME     Modified time is greater than (+N); less than (-N);
                        or exactly (N) days

address@hidden test]# /usr/bin/find . -type l
./link

== GNU bash ==

Some other GNU tools, including [[ in GNU bash correctly detect the symlink.

address@hidden test]# bash --version
GNU bash, version 3.2.57(2)-release (i686-pc-linux-gnu)
Copyright (C) 2007 Free Software Foundation, Inc.

address@hidden test]# type [[
[[ is a shell keyword 

address@hidden test]# for i in *; do [[ -h $i ]] && echo $i; done
link

= find -printf behaviour for %y =

The second problem is that %y behaves differently depending upon whether or
not %Y is also used.

address@hidden test]# find . -type f -printf "%y %Y " -ls
f f       450      0 -rw-rw-rw-   1  admin    administrators        0 Sep 17
07:43 ./file
l f    206257      4 lr--r--r--   1  admin    administrators       18 Sep 17
07:43 ./link -> file

address@hidden test]# find . -type f -printf "  %Y " -ls
  f       450      0 -rw-rw-rw-   1  admin    administrators        0 Sep 17
07:43 ./file
  f    206257      4 lr--r--r--   1  admin    administrators       18 Sep 17
07:43 ./link -> file

address@hidden test]# find . -type f -printf "%y   " -ls
f         450      0 -rw-rw-rw-   1  admin    administrators        0 Sep 17
07:43 ./file
f      206257      4 lr--r--r--   1  admin    administrators       18 Sep 17
07:43 ./link -> file

Both work correctly on the same system on ext4 filesystems.





    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?54667>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/