php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #65717 stat() should supply nano second granularity
Submitted: 2013-09-19 21:54 UTC Modified: 2013-09-21 00:45 UTC
From: addw at phcomp dot co dot uk Assigned: aharvey
Status: Assigned Package: Filesystem function related
PHP Version: Irrelevant OS: Any
Private report: No CVE-ID:
Have you experienced this issue?
Rate the importance of this bug to you:

 [2013-09-19 21:54 UTC] 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.


Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2013-09-20 04:24 UTC] 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-20 08:30 UTC] 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-21 00:45 UTC] aharvey@php.net
-Status: Open +Status: Assigned -Assigned To: +Assigned To: aharvey
 [2013-09-21 00:45 UTC] 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.
 
PHP Copyright © 2001-2017 The PHP Group
All rights reserved.
Last updated: Tue Aug 29 15:01:52 2017 UTC