Re: The return of the return of crunch time (2.5 merge candidate list 1.6)

[Andrew Pimlott <andrew@pimlott.net>]

On Tue, Jan 15, 2002 at 12:44:28PM -0500, Pavel Machek wrote:
> > The point of my patchkit is to allow the file systems
> > who support better resolution to handle it properly. Other filesystems
> > are not worse than before when they flush inodes (and better off when
> > they keep everything in ram for your build because then they will enjoy 
> > full time resolution) 
> 
> What about always rounding down even when inode is
> in memory? That is both simple and consistent.

I assume you mean, for filesystems that don't support high
resolution.  That is what I think should be done as well.  People
have gotten along with second resolution all these years, so it's no
great tragedy to make them continue; plus, it seems like the common
filesystems will support high resolution soon anyway.

Paul Eggert listed lots of programs that could be broken if
timestamps jump around.  They could all implement heuristic
work-arounds, but that would be 1) a miracle and 2) a waste of
effort.

The only issue (as far as I can tell) is knowing when to round.
Hard-coding a list of filesystems seems reasonable (though even that
could be wrong if I load a newer filesystem module).  Ideally,
though, you would add a simple hook into the filesystem that asks it
to round the timestamp for you.  This would also accommodate
filesystems that don't store seconds or nanoseconds, but some other
resolution.

Andrew