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@FreeBSD.org
Reporter: bugzilla.free...@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.
_______________________________________________
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
