Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 155406 - make thinks file is out of date if it has the same modification time as prerequisite
Summary: make thinks file is out of date if it has the same modification time as prere...
Status: CLOSED DUPLICATE of bug 145976
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel
Version: 4.0
Hardware: i386
OS: Linux
Target Milestone: ---
: ---
Assignee: Stephen Tweedie
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2005-04-20 03:51 UTC by Andrew Schultz
Modified: 2007-11-30 22:07 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2005-09-30 15:38:07 UTC
Target Upstream Version:

Attachments (Terms of Use)

Description Andrew Schultz 2005-04-20 03:51:41 UTC
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 11:30:38 UTC
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 15:19:10 UTC
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 08:07:43 UTC
If that depends on the exact kernel, then it is a kernel issue, not a make one.

Comment 4 Stephen Tweedie 2005-09-30 15:38:07 UTC
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.