[Bug 222698] find(1)'s -newer expression doesn't work with symbolic links if '-P' (the default) is requested.

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222698

            Bug ID: 222698
           Summary: find(1)'s -newer expression doesn't work with symbolic
                    links if '-P' (the default) is requested.
           Product: Base System
           Version: 11.1-STABLE
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Many People
          Priority: ---
         Component: bin
          Assignee: freebsd-bugs at FreeBSD.org
          Reporter: bugzilla.freebsd at omnilan.de

Utilizing find(1)'s 'newer' primary expression is broken with symbolic links.

According to the man page, -P should be the default behaviour, but even if
explicitly defining -P, find uses timestamp information from the file
referenced by the link, not the link itself.

To see in action (copy'n'pastable for sh and csh):

[ -e /tmp/find-test ] && rm -R /tmp/find-test
mkdir /tmp/find-test && cd /tmp/find-test
ln -s fILE lINK-to-fILE && sleep 1
echo "Created after lINK-to-fILE" > fILE2 && sleep 1
echo "Newest in the hood" > fILE && sleep 1
find . -newermm lINK-to-fILE

It doesn't return fILE2 nor fILE, while stat(1) clearly confirms newer m_times
for fILE and fILE2 compared to lINK-to-fILE ( 'stat -f "%N: %Sm" *' ).

It's possible that find(1) hasn't been working like expected for a quiet long
time.  I first recognized strange results arround FreeBSD 8.0 but haven't had
time|need to investigate.
More precisely, I thought that the error was in my backup script due to
timestamp precision changes, which changed around that time if I remember
correctly.  But since timestamp comparings is a fallback mechanism in my
script, never needed until yesterday in real world, I haven't paid any
attention until today.

To falsify find(1)'s misbehaviour, continue the test above with:

touch -m -t `stat -f %Sm -t %y%m%d%H%M.%S lINK-to-fILE` fILE
find . -newermm lINK-to-fILE

Now you get the result which was expected before.

Why don't I just use 'touch -r' ?  Well, tried that of course, but I had to
find out that touch(1) is not using the m_time of the link, but from the file
referenced by the link.  touch(1) hasn't options which influence that and
doesn't state default behaviour...

Will see if I can identify the problem in the source of find(1) and add
comments as soon as I found anything.
But I hope people with better C skills jump in!

Even if it's a old bug, it's a very nasty one, because it can affect user's
data...  So high priority IMHO.

-harry

-- 
You are receiving this mail because:
You are the assignee for the bug.