The slower I/O as a traditional bottleneck on Windows which is
the target of this patch. The recursive path resolution, while being
an allround solution, is expensive when it comes to the common case.
Files with proper ACLs set can be resolved in one go by usage of specific
API. Those are available since Vista, so actually can be called old. Those
simpler api is used for the cases where no CWD_EXPAND is requested. For
the cases where ACLs are improper, the existing solution based on
FindFirstFile still does good job also partially providing quirks. Cases
involing reparse tags and other non local filesystems are also partially
server by new APIs.
The approach uses both APIs - the quick one for the common case still
integrating realpath cache, and the existing one as a fallback. The tests
show the I/O load drop on the realpath resolution part due to less
system calls for the sub part resolution of paths. In most case it is
justified, as the sub parts were otherwise cached or unused as well. The
realpath() implementation in ioutil is also closer to the POSIX.
This effectively allows a UNIX like semantics for deleting files
with an open handle. Some OS related limitations still persist,
but the Windows 95 times can be considered as definitely over.
Having `int` there is no real profit in the size or speed, while unsigned
improves security and overall integration. ZPP supplied strings can
be then accepted directly and structs can be still handled with smaller
unsigned types for size reasons, which is safe. Yet some related places
are to go.
basic move tsrm_realpath_r to size_t
fix conditions and sync with affected places
touch ocurrences of php_sys_readlink usage
follow up on phar path handling
remove duplicated check
move zend_resolve_path and related pieces to size_t
touch yet resolve path related places
remove cast
missing pieces
missing piece
yet cleanups for php_sys_readlink for ssize_t
fix wrong return
Primarily related to the path handling datatypes, to avoid unnecessary
casts, where possible. Also some rework to avoid code dup. Probably
more places are to go, even not path related, primarily to have less
casts and unsigned integers where possible. That way, we've not only
less warnings and casts, but are also safer with regard to the
integer overflows. OFC it's not a panacea, but still significantly
reduces the vulnerability potential.
If this does not break the Unix system somehow, I'll be amazed. This should get most of it out, apologies for any errors this may cause on non-Windows ends which I cannot test atm.
