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

Edit report at https://bugs.php.net/bug.php?id=69472&edit=1 ID: 69472 Comment by: jan dot starke at t-systems dot com 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 Block user comment: N Private report: N New Comment: 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 Previous Comments: ------------------------------------------------------------------------ [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