Re: [PATCH 1/6] xstat: Add a pair of system calls to make extended file stats available

[Ben Hutchings <ben@decadent.org.uk>]

[-- Attachment #1: Type: text/plain, Size: 1490 bytes --]

On Mon, 2012-04-30 at 16:30 -0400, J. Bruce Fields wrote:
> On Mon, Apr 30, 2012 at 09:15:56PM +0100, David Howells wrote:
> > Ben Hutchings <ben@decadent.org.uk> wrote:
> > 
> > > Try 86,400 seconds - the actual granularity of atime on VFAT.
> > 
> > 24 hours?  Really?  I guess it makes the updating of atime on the media
> > something you can be lazy about.
> > 
> > > (For mtime it's 2 seconds, and for ctime 0.01 seconds.)
> 
> Does it actually support ctime, or is there some confusion here between
> unix ctime and file creation time?

I think there is some confusion, yes.  The Linux implementation stores
ctime, but the documentation I can find refers to creation time.

> > Sigh.  Okay.  Ugh.  I guess I need separate granularities after all...  Not
> > only that, but a 32-bit integer isn't sufficiently capacious to hold the full
> > range I now know about (1nS up to 1 day).
> > 
> > I wonder if granularity should be left to a statfsxat() syscall?
> > 
> > And I know Linus didn't like it, but I wonder if I can pack it in to a 32-bit
> > word either by doing an x * 10^y thing.
> 
> Does it matter if we don't get vfat's atime granularity exactly right?
> Is anyone ever going to use it for anything?

I thought the point of this extension was to let callers know what
information we *really* have.  In which case, let's not cop out on this.

Ben.

-- 
Ben Hutchings
Design a system any fool can use, and only a fool will want to use it.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]