Date: Sat, 30 Sep 2017 12:37:18 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-bugs@FreeBSD.org Subject: [Bug 222698] find(1)'s -newer expression doesn't work with symbolic links if '-P' (the default) is requested. Message-ID: <bug-222698-8@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D222698 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.freebsd@omnilan.de Utilizing find(1)'s 'newer' primary expression is broken with symbolic link= s. 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_ti= mes 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 lo= ng time. I first recognized strange results arround FreeBSD 8.0 but haven't h= ad 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 fi= le 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 --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-222698-8>