Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 155406 - make thinks file is out of date if it has the same modification time as prerequisite
make thinks file is out of date if it has the same modification time as prere...
Status: CLOSED DUPLICATE of bug 145976
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Stephen Tweedie
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2005-04-19 23:51 EDT by Andrew Schultz
Modified: 2007-11-30 17:07 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-09-30 11:38:07 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Andrew Schultz 2005-04-19 23:51:41 EDT
Description of problem:
make sometimes thinks a target is out of date when its modification time is
identical to its prerequisite.  It consistently fails in some situations and
then consistently works in others.

Version-Release number of selected component (if applicable):
make-3.80-5 (FC3 and RHEL4)

Steps to Reproduce:
1. use this Makefile in /tmp
bar:    foo
        cp -p foo bar

3. touch foo
4. make
5. make
6. make

Actual results:
make copies the file every time even though the files have the same modification
time.  If the above happens to work, touch foo, and try again.  That seems to
always fail.  Then, "cp -p bar foo".  Then make recognizes the file is up to date.

Expected results:
make realizes the modification times are the same and stops trying to copy it.
Comment 1 Jakub Jelinek 2005-04-24 07:30:38 EDT
What filesystem is this on?
I certainly can't reproduce this on ext3:
touch foo; make; make; make
cp -p foo bar
make: `bar' is up to date.
make: `bar' is up to date.
Comment 2 Andrew Schultz 2005-04-24 11:19:10 EDT
I was testing this on ext3 for FC3 and RHEL4.  I retested on FC3 now and it's
working.  The only thing I can think of that would have fixed this was a kernel
upgrade (2.6.10-1.770_FC3 => 2.6.11-1.14_FC3).  RHEL4 with 2.6.9-5.0.5 is still
a problem.
Comment 3 Jakub Jelinek 2005-04-25 04:07:43 EDT
If that depends on the exact kernel, then it is a kernel issue, not a make one.
Comment 4 Stephen Tweedie 2005-09-30 11:38:07 EDT
The reason the kernel is implicated is that RHEL-4 GA kernel honours
sub-microsecond timestamp updates on ext3 in memory (though not on disk.) 
Upstream has disabled that, and this has been back-ported to RHEL-4 for U2.  I
can reproduce this on RHEL-4 GA but not on the U2 kernel, so I'm closing this as
a dup.

Note that this problem still occurs even on U2 if you use the tmpfs filesystem,
as that does have true nanosecond timestamp support; cp -p only updates the
microsecond, but not nanosecond, component (because of the utimes(2) granularity
limit), and it doesn't round, so drops the lower 3 decimal digits of the
nanosecond cound.  If this is still a problem, please reopen against coreutils.

*** This bug has been marked as a duplicate of 145976 ***

Note You need to log in before you can comment on or make changes to this bug.