- Unbelievable - 4 Updates
| David Brown <david.brown@hesbynett.no>: Aug 11 08:28AM +0200 On 10/08/2023 17:49, Scott Lurndal wrote: > to require additional storage space on the volume, that's a cost. > In any case, none of the existing filesystems, widely used, would > be willing to make such a change, so your point is moot. ext4 has nanosecond resolution for its timestamps - and that is, I would argue, quite a widely used filesystem. |
| Bonita Montero <Bonita.Montero@gmail.com>: Aug 11 09:17AM +0200 Am 11.08.2023 um 08:28 schrieb David Brown: > ext4 has nanosecond resolution for its timestamps - and > that is, I would argue, quite a widely used filesystem. And what's the API to use that ? For sure not stat(), because that uses time_t timestamps. |
| Ben Bacarisse <ben.usenet@bsb.me.uk>: Aug 11 12:02PM +0100 >> ext4 has nanosecond resolution for its timestamps - and >> that is, I would argue, quite a widely used filesystem. > And what's the API to use that ? Various, including stat(2). > For sure not stat(), because that uses time_t timestamps. Modern stat(2) uses struct timespec fields with #defines that make st_[acm]time access the 'seconds' part of the timespec. -- Ben. |
| Paavo Helde <eesnimi@osa.pri.ee>: Aug 11 03:31PM +0300 11.08.2023 10:17 Bonita Montero kirjutas: >> that is, I would argue, quite a widely used filesystem. > And what's the API to use that ? > For sure not stat(), because that uses time_t timestamps. Some quick googling says: "Since kernel 2.5.48, the stat structure supports nanosecond resolution for the three file timestamp fields." Glibc is exposing these fields in form stat.st_mtim.tv_nsec et al. |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment