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@xxxxxxxxxxxxxxx> 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:
signature.asc
Description: This is a digitally signed message part
