Req #65717 [Asn->Opn]: stat() should supply nano second granularity
Edit report at https://bugs.php.net/bug.php?id=65717&edit=1
ID: 65717
Updated by: kalle@php.net
Reported by: addw at phcomp dot co dot uk
Summary: stat() should supply nano second granularity
-Status: Assigned
+Status: Open
Type: Feature/Change Request
Package: Filesystem function related
Operating System: Any
PHP Version: Irrelevant
-Assigned To: aharvey
+Assigned To:
Block user comment: N
Private report: N
Previous Comments:
------------------------------------------------------------------------
[2013-09-21 00:45:25] aharvey@php.net
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.
------------------------------------------------------------------------
[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
Thread (7 messages)