Bug #69472 [Fbk]: php_sys_readlink ignores misc errors from GetFinalPathNameByHandleA

Edit report at https://bugs.php.net/bug.php?id=69472&edit=1 ID: 69472 Updated by: ab@php.net Reported by: jan dot starke at t-systems dot com Summary: php_sys_readlink ignores misc errors from GetFinalPathNameByHandleA Status: Feedback Type: Bug Package: Filesystem function related Operating System: Windows PHP Version: Irrelevant -Assigned To: +Assigned To: ab Block user comment: N Private report: N New Comment: Thanks for the follow up. Please explain why the usage of GetFileInformationByHandleEx would be better. From tho doc, both support the same technologies. Regarding your patch - yeah, you made a good catch. Are you already using the patched version? If so, you could see something interesting in the error logs. Btw. what kind of shares are used on those hosts? Thanks. Previous Comments: ------------------------------------------------------------------------ [2015-04-20 21:02:19] jan dot starke at t-systems dot com Not really. We currently do not know the reason why GetFinalPathNameByHandle returns 0. We host a large number of microsites, but we observe this behaviour only with a very small number of sites. Additionally, this problems seems to be IIS/Fast-CGI related. It did not occur with php.exe until now, only with php-cgi.exe when run within IIS. To write a test, we must construct a case where GetFinalPathNameByHandle reliably returns 0. As soon as we do not understand the reason for the behaviour of GetFinalPathNameByHandle, we cannot create a working test. As soon as we know more about the root cause of our specific problem, I will let you know. BTW; I suppose there is another problem with GetFinalPathNameByHandle itself: We observed that simply renaming one of the folders in open_basedir (and changing the setting accordingly) made the problem go away. Possibly, a better fix was to not use GetFinalPathNameByHandle at all, but switch to GetFileInformationByHandleEx... Regards, Jan ------------------------------------------------------------------------ [2015-04-20 08:15:10] ab@php.net Thanks for the patch. Could you please add a test for this case as well (check any of the current *.phpt cases for an example, maybe in ext\standard\tests\file)? Thanks. ------------------------------------------------------------------------ [2015-04-16 18:15:58] jan dot starke at t-systems dot com Description: ------------ The Windows API functions GetFinalPathNameByHandleA, which is used by php_sys_readlink, has two different ways of returning an error: (1) the return value is different from cchFilePath (which is MAXPATHLEN in php_sys_readlink). This error is raised if the buffer to store the pathname is not large enough to hold the pathname. (2) the return value is zero. This error can be caused by one of ERROR_PATH_NOT_FOUND, ERROR_NOT_ENOUGH_MEMORY or ERROR_INVALID_PARAMETER. Unfortunately, the second case is not handled by php_sys_readlink. As a result, php_sys_readlink writes an empty string to target and returns 0 as its length, which both is incorrect. Expected result: ---------------- php_sys_readlink should return -1 if GetFinalPathNameByHandleA returns 0: <code> if (dwRet >= MAXPATHLEN || dwRet == 0) { return -1; } </code> Actual result: -------------- if GetFinalPathNameByHandleA returns 0, php_sys_readlink returns 0 :-( This brakes php_check_specific_open_basedir, which in our case creates some problems <code> if (dwRet >= MAXPATHLEN) { return -1; } </code> ------------------------------------------------------------------------ -- Edit this bug report at https://bugs.php.net/bug.php?id=69472&edit=1