I can't reproduce this issue, neither on Windows 10 x64 with
PHP 5.6.22 VC11 x64 Non Thread Safe (2016-May-26 18:22:21), nor on
3v4l.org, see <https://3v4l.org/Wig5o>.

Please make sure that you have error_reporting=-E_ALL, and double-
check that there are no warnings or notices reported.

I double check error reporting it's on E_ALL both in my php.ini (and i double check that i was viewing the right php.ini by checking which one was loaded) and also i put error_reporting(E_ALL); at the top (new script at the bottom of this comment). I don't see any warnings or notices, exact output at bottom of comment. My exact php version is this one: php-5.6.20-Win32-VC11-x64.zip

==== Script
<?php
error_reporting(E_ALL);
var_dump(
  file_exists(sys_get_temp_dir()),
  is_writable(sys_get_temp_dir()),
  sys_get_temp_dir(),
  tempnam(sys_get_temp_dir(), 'php'),
  tempnam(sys_get_temp_dir(), 'aaa')
);
==== End script

==== Console
C:\dev>php test.php
bool(true)
bool(true)
string(34) "C:\Users\plagas\AppData\Local\Temp"
bool(false)
string(46) "C:\Users\plagas\AppData\Local\Temp\aaaE26E.tmp"

==== End Console

Forgot to change the username in my output, but it's the same user ..

> 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/>

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.

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.

> 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>

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).