From owner-freebsd-bugs@freebsd.org Sat Sep 30 12:37:18 2017 Return-Path: Delivered-To: freebsd-bugs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DB283E2736B for ; Sat, 30 Sep 2017 12:37:18 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BB43D6F267 for ; Sat, 30 Sep 2017 12:37:18 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v8UCbIcE081964 for ; Sat, 30 Sep 2017 12:37:18 GMT (envelope-from bugzilla-noreply@freebsd.org) 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. Date: Sat, 30 Sep 2017 12:37:18 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: 11.1-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: bugzilla.freebsd@omnilan.de X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Sep 2017 12:37:19 -0000 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.=