Edit report at https://bugs.php.net/bug.php?id=65717&edit=1
ID: 65717 Updated by: ahar...@php.net Reported by: addw at phcomp dot co dot uk Summary: stat() should supply nano second granularity -Status: Open +Status: Assigned Type: Feature/Change Request Package: Filesystem function related Operating System: Any PHP Version: Irrelevant -Assigned To: +Assigned To: aharvey Block user comment: N Private report: N New Comment: I've got a patch that implements this, but I'm not totally happy with it right now â it works well enough for systems that provide this, but results in inconsistent behaviour for stream wrappers: whether the nanosecond fields are persisted depends on what's defined in sys/stat.h, since we use the system struct stat even though stream wrappers are theoretically decoupled from the OS. The better fix is probably to have our own php_stat struct that contains a consistent set of fields and then fill it in based on what the system provides, which we kind of do already at a higher level in stat() and friends. Since I got most of the way through the first version anyway, I've pushed it to GitHub: https://github.com/LawnGnome/php-src/compare/fr65717. Will continue tinkering with this to see if I can abstract away the system-specific stat struct as described above. Previous Comments: ------------------------------------------------------------------------ [2013-09-20 08:30:27] addw at phcomp dot co dot uk My immediate problem is that I am trying to generate ETags that are compatible with those generated by Apache. Apache 'MTime' is of granularity microseconds. Unless I can determine the file modification time to an accuracy better than what PHP gives me I cannot do this. More to the point: if a facility is available, someone will find a use for it. It will not break backwards compatability since scripts that are not interested just don't look for the new members in the array. ------------------------------------------------------------------------ [2013-09-20 04:24:01] metamarkers at gmail dot com What would be a use case of this? Is there something inherently wrong with unix timestamps? Hardware has millisecond latency, I don't understand where having granularity down to the CPU cycle would be significant. ------------------------------------------------------------------------ [2013-09-19 21:54:21] addw at phcomp dot co dot uk Description: ------------ Some systems (eg Linux on kernel > 2.5.48) the 3 timestamp fields may be available with resolution of nanosecond. If these are available stat() should return in the array 3 extra members : atimensec, ctimensec and mtimensec. The resolution available also depends on the underlying file system. ------------------------------------------------------------------------ -- Edit this bug report at https://bugs.php.net/bug.php?id=65717&edit=1
