differences in the time precision used within linux can bite you

[Ray Liere]

I am using RHEL4 and encountered a problem which is essentially caused by the
fact that efforts are underway to increase the precision of timestamps that are
used by various linux commands. However, as these efforts are implemented,
one can get non-intuitive results.

My particular situation is demonstrated by this:
	# echo xxx > jnk
	# ls --full-time jnk
	-rw-------  1 root root 4 2008-01-31 18:40:27.879358240 -0800 jnk
	# cp -p jnk jnkcopy
	# ls --full-time jnk*
	-rw-------  1 root root 4 2008-01-31 18:40:27.879358240 -0800 jnk
	-rw-------  1 root root 4 2008-01-31 18:40:27.879358000 -0800 jnkcopy

Note that the timestamp values are NOT the same.

I ran into this when (trying) to use cp -p as a way of remembering exactly
when the original version of a file was created (i.e., I later then compared
the timestamps of jnk and jnkcopy ... but due to the loss of precision
in the copy, they will rarely be equal).

I sent a bug report to gnu, and they were very helpful.

The situation as I understand it is this: an effort is underway to increase
the precision of timestamps used in linux into the nanosecond range,
but that effort is necessarily actually implemented for different parts
of linux at different times, so one can have the above type of thing occur.

Thus this is not just a "problem" with using cp.

I have access to several different linux/cygwin installations, and so ran
the above test and found that the problem is fairly common. So this is not
a criticism of RedHat.

I would by the way be interested if anyone at RedHat cares to comment on
the state of this issue in RHEL5. I am still on RHEL4 (and so are many
people). I was thinking anyway of going to RHEL5, but it would be nice
to know where RHEL5 is at with respect to the nanosecond consistency issue.

Ray Liere