[00:48:01] --- Russ has left: Disconnected [00:49:29] --- lama has become available [01:34:38] --- sxw has become available [02:51:01] --- haba has become available [04:12:41] --- haba has left [04:16:05] --- haba has become available [06:57:29] --- reuteras has left [07:27:12] --- deason has become available [08:05:36] --- lama has left [09:25:21] --- haba has left [09:28:44] --- meffie has left [10:25:38] --- mfelliott has left [10:25:55] --- mfelliott has become available [10:37:11] deason - so what's the use case for <1s timestamp resolution? (that needs to be answered in the mail thread...) [10:39:34] I thought that was answered in <20110311114739.13b8bd19.adeason@sinenomine.net> [10:40:17] make? [10:41:58] I see discussions of implementation and design issues but never any actual -requirements- [10:42:00] he means, specifying what the resolution of the time value is [10:42:22] ie, 'someone needs to do X, and that requires <1 s granularity' [10:42:30] oh, or maybe you don't mean that [10:42:39] sorry, misinterpreted that comment [10:43:10] "someone wants to store file metadata with <1s res"; 'make' is indeed, a good example [10:44:38] it's not clear to me why 'make' is a useful use case. [10:45:15] ie, 'make' has been around for a long, long time, so why is this requirement coming up -now-? [10:45:31] make needs to determine in what order two events occured; usually, the two events "I generated this file" and "the source file was modified" [10:46:22] > why is this requirement coming up -now-? It's not. It's been around for several years. A long, long time ago it took several minutes to compile even the simplest source file. Today it takes several milliseconds. [10:46:27] also for server-side operations; a lot of things can happen in the span of 1 second, so knowing _when_ during the second would be very useful [10:46:57] Yes, being able to know the _relative_ order of things is often important, and 1s-resolution timestamps are useless for that. [10:47:26] some things are worked around by sleeping, or by being very inefficient, so it'd be good to not need to do that [10:50:22] that sounds to me like you're trying to use a distributed filesystem as a synchronization mechanism. is that what you're aiming towards? [10:50:58] HuH? [10:51:19] that was re: deason's comment "some things are worked around by sleeping, or by being very inefficient, so it'd be good to not need to do that". [10:52:07] openafs itself does that; but userland stuff probably does, too [10:52:30] don't all other filesystems support <1s times? [10:52:35] No. He means, sometimes tools that know they will need to know the order in which files were touched will sleep for one second between operations, to ensure that each file has a distinct timestamp even on antiquated filesystems that don't have subsecond timestamp resolution. [10:52:48] > all certainly not [10:52:56] yeah yeah, not "all" [10:53:00] steven, copying files from NTFS to AFS to NTFS fails to preserve timestamp information at the originally recorded granularity [10:53:03] modern ones [10:53:36] nfs, ntfs, extN, veritas stuff... uh, jfs? [10:53:38] Also s/NTFS/ext3/g [10:55:58] it seems reasonable to me, then, that the use case is 'because many of the underlying filesystems and other network filesystems already support this'. [10:56:52] the question about use case was for the "resolution" field not the timestamp itself. [10:58:44] --- mmeffie has become available [10:59:21] The question was "so what's the use case for <1s timestamp resolution?" [11:03:08] you guys answered my questions, tx. [11:04:20] well, the original question was also phrased like > I see discussions of implementation and design issues but never any actual -requirements- to which I suppose the answer is that it's not _required_ -- we can continue without it -- but it's a feature [11:25:25] --- rra has become available [11:33:13] --- mmeffie has left [12:13:29] --- lars.malinowsky has become available [12:33:05] --- meffie has become available [12:54:30] --- jaltman/FrogsLeap has left: Disconnected [13:18:07] --- Simon has become available [13:21:30] I would still be interested in a use case for the resolution field [13:56:31] --- Simon has left [14:17:35] --- lars.malinowsky has left [15:28:48] > use case again, I thought that was explained on the list [15:29:02] for specifically file mtime I recognize it may not make much sense, and am reconsidering it there.... [15:31:24] --- deason has left [15:33:11] I'm not convinced that for any case it makes much sense. Or at least, not enough sense that it warrants adding resolution information to a new generic time format. [15:33:42] I think, at the end of the day, you should just be able to degrade to using the closest approximation that the peer claims to support. [17:02:12] --- jaltman/FrogsLeap has become available [17:36:41] --- rra has left: Disconnected [17:56:19] --- Russ has become available [17:56:19] --- Russ has left: Lost connection [17:56:53] --- Russ has become available [21:19:24] --- Russ has left: Disconnected