[OS: Fedora Linux 14, using their coreutils-8.5-7.fc14.i686 package]
Using a single "mv" command with no switches, I moved a tree of 302968
files from an ext4 partition without nsec timestamp support (due to
128-byte inodes) to a newly-created ext4 partition with support for nsec
timestamps (256-byte inodes).
Afterward, however, upon examining the results I noticed something quite
unexpected: a small percentage of the files (1580 to be exact) now show
non-zero values in the nsec parts of their mtimes and atimes.
Here are some examples:
> # find xxx -type f -printf '%t - %p\n' | fgrep -v '.0000000000'
> ...
> Sun Mar 25 20:31:58.0994432936 2007 - xxx/usr/include/w32api/wingdi.h
> Sun Mar 25 20:31:45.0994432936 2007 - xxx/usr/include/w32api/ks.h
> Sun Mar 25 20:32:03.0994432936 2007 - xxx/usr/include/w32api/ddk/d4iface.h
> Wed Dec 6 13:02:08.0808157700 2006 -
> xxx/usr/share/locale/et/LC_MESSAGES/findutils.mo
> Tue Nov 15 04:37:59.0808157700 2005 -
> xxx/usr/share/locale/et/LC_MESSAGES/lynx.mo
> Sun Jul 9 17:08:11.0994432936 2006 -
> xxx/usr/share/locale/hr/LC_MESSAGES/make.mo
> Fri Nov 17 00:10:59.0994432936 2006 - xxx/usr/share/terminfo/a/att4424
> Tue Mar 13 07:17:21.0994432936 2007 - xxx/lib/python2.5/encodings/cp1026.pyo
> ...
The nsec values mostly alternate between ".0994432936" and
".0808157700". ("stat" reports the same times, by the way.)
Has anyone seen this before? Thus far, I haven't been able to come up
with a reproducible test case.
Thanks.
--
Jordan Russell
