Re: -newer vs. FAT two second resolution

[James Youngman]

On Sat, Apr 12, 2008 at 12:13 AM, <address@hidden> 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): 200\d/'|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.
>
> http://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.