Bug #72317 [Com]: tempnam fails with prefix "php"

Edit report at https://bugs.php.net/bug.php?id=72317&edit=1 ID: 72317 Comment by: flip101 at gmail dot com Reported by: flip101 at gmail dot com Summary: tempnam fails with prefix "php" Status: Not a bug Type: Bug Package: *Directory/Filesystem functions Operating System: Windows 10 64 bits PHP Version: 5.6.20 Assigned To: cmb Block user comment: N Private report: N New Comment: Agreed cmb, though note that there didn't seem to be a limit 65534 files because there were more than 80.000 files and php was still able to create files with prefix "aaa" (because it didn't exhaust the possible combinations for this prefix). Previous Comments: ------------------------------------------------------------------------ [2016-06-06 11:36:20] cmb@php.net > I have 65.535 files which look like php####.tmp where #### can > be 1 to 4 characters and seem to be counting up. […] and assumed > php would delete the file if i don't use it […] Well, that is documented[1]: | If PHP cannot create a file in the specified dir parameter, it | falls back on the system default. On NTFS this also happens if | the specified dir contains more than 65534 files. In this case there's no fallback on the system default, because that has already been explicitly requested. And: | Note, that you need to remove the file in case you need it no | more, it is not done automatically. > But i think the issue is resolved at this point. ACK. Thanks for your quick feedback. :) [1] <http://php.net/manual/en/function.tempnam.php> ------------------------------------------------------------------------ [2016-06-06 11:25:31] flip101 at gmail dot com Hi ab, i captured the output of Sysinternals Process Monitor. I noticed that when trying to generate a file the file already exist (i went into the directory and indeed the file is there). I have 65.535 files which look like php####.tmp where #### can be 1 to 4 characters and seem to be counting up. However all these files were created on the day that i reported this issue. What i think happened is that i had the tempnamp() in a while loop (which had a wrong stop condition) and assumed php would delete the file if i don't use it (because i thought the file was temporary because of the function name). When i was getting errors there i started making the test case which of course failed as well. Let me know if you want to have the output of Process Monitor, or @cmb if you want to test this with a different php version. But i think the issue is resolved at this point. ------------------------------------------------------------------------ [2016-06-06 07:44:17] ab@php.net Thanks for the report. Can't reproduce as well. Also it's unlikely an issue with exactly x64 PHP5, as the I/O layer is same. @flip101 does the same happen when using a dir different from temp? For one, could you please post the relevant part of the procmon output when running into this issue? The Process Monitor is fetcheable from sysinternals.com. Thanks. ------------------------------------------------------------------------ [2016-06-03 15:12:04] cmb@php.net > My exact php version is this one: php-5.6.20-Win32-VC11-x64.zip Running your latest test script on this very version: bool(true) bool(true) string(31) "C:\Users\cmb\AppData\Local\Temp" string(43) "C:\Users\cmb\AppData\Local\Temp\phpB8D1.tmp" string(43) "C:\Users\cmb\AppData\Local\Temp\aaaB8E2.tmp" So, I still can't reproduce the issue. Anyhow, note[1]: | The x64 builds of PHP 5 for Windows are experimental, I suggest you try with an x86 build of PHP 5.6.22. [1] <http://windows.php.net/download/> ------------------------------------------------------------------------ [2016-06-03 13:57:27] flip101 at gmail dot com Forgot to change the username in my output, but it's the same user .. ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=72317 -- Edit this bug report at https://bugs.php.net/bug.php?id=72317&edit=1