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.

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.

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.