Re: -newer vs. FAT two second resolution

Oops, pasted wrong. OK:
$ cd /some_Linux_dir; stat y
Modify: 2008-04-09 11:11:11.000000000 +0800
$ cp -a y /vfat
$ umount /vfat; mount /vfat
$ stat /vfat/y
Modify: 2008-04-09 11:11:10.000000000 +0800

Anyway, please try
$ cd some_[V]FAT_directory_of_yours
$ stat *|perl -nwe 'print if /(Access|Modify|Change):
200d/'|sort

One notes that Change is both odd and even seconds, Modify
is only
even seconds, and Access has no seconds at all.

ht
tp://en.wikipedia.org/wiki/File_Allocation_Table
  Note that the seconds is recorded only to a 2 second
  resolution. Finer resolution for file creation is
  found at offset 0x0d.

So -newer will be fooled because it only thinks in one
second frames
instead of rolling with the current filesystem punches.

Interestingly, find2perl output escapes blame, as now the
raw
comparison is being done by the user, instead of asking find
to tell
it which is newer.

And -anewer: hmmm, that needs an window of 24 hours...
yikes.

Hmmm, "finer resolution for file creation is found at
offset..." maybe
stat et al should know about that...

On Sat, Apr 12, 2008 at 12:13 AM, <jidannijidanni.org> wrote:
> Oops, pasted wrong. OK:
> $ cd /some_Linux_dir; stat y
> Modify: 2008-04-09 11:11:11.000000000 +0800
>
> $ cp -a y /vfat
> $ umount /vfat; mount /vfat
> $ stat /vfat/y
> Modify: 2008-04-09 11:11:10.000000000 +0800
>
> Anyway, please try
> $ cd some_[V]FAT_directory_of_yours
> $ stat *|perl -nwe 'print if /(Access|Modify|Change):
200d/'|sort

Are you trying to report a problem with findutils?   I can't
see any
find command in there.   What problem exactly are you asking
us to
solve?

> One notes that Change is both odd and even seconds,
Modify is only
> even seconds, and Access has no seconds at all.
>
> ht
tp://en.wikipedia.org/wiki/File_Allocation_Table
>  Note that the seconds is recorded only to a 2 second
>  resolution. Finer resolution for file creation is
>  found at offset 0x0d.

POSIX doesn't say anything about creation time.  The
st_ctime member
of struct stat is inode-change-time, not creation time.   
BSD
supports file-creation-time, but it stores that information
elsewhere.

> So -newer will be fooled because it only thinks in one
second frames
> instead of rolling with the current filesystem
punches.

The -newer test, and find generally, deals only with the
information
the OS gives it.


> Interestingly, find2perl output escapes blame, as now
the raw
> comparison is being done by the user, instead of asking
find to tell
> it which is newer.
>
> And -anewer: hmmm, that needs an window of 24 hours...
yikes.
>
> Hmmm, "finer resolution for file creation is found
at offset..." maybe
> stat et al should know about that...

But stat is a user program.  It has no access to the raw
media.   It
sounds to me as if your problem relates to the kernel you
are using,
and that you wish it did something else, I'm not certain
quite what.

Several emails later, I still don't know what, precisely,
you are
suggesting should be changed.   If you are reporting a bug,
please
demonstrate it.   If you are requesting an enhancement,
please be
specific about the change you suggest; specific enough for
everybody
to be sure that it won't make find POSIX-incompliant or
break users'
scripts without warning.

James.