file_directory_temp() fails to set valid temporary directory on Windows

can you change it back to wrongly patch (sites/default/files\tmp) and click SAVE.

if passed we may need to add some more checks, otherwise this issue can be "Closed (works as designed)".

(as I know windows accept both "\" or "/")

I also experienced this problem. This seems quite important, as it prevents modules and themes from being installed. Bumping priority up to Major.

Additional info: A colleague who experienced this error on Mac found it worked fine on Windows. (Acquia Drupal Stack Installer for the AMP in both cases.)

The problem here is file_directory_temp() in includes/file.inc is not setting the default temporary directory correctly.

// If no directory has been found default to 'files/tmp' or 'files\\tmp'.
$temporary_directory = variable_get('file_public_path', conf_path() . '/files') . $path_delimiter . 'tmp';

where earlier $path_delimiter = '\\'; since it detected a Windows operating system. This creates the string you have above...
'sites/default' . '/files' . '\\' . 'tmp'

Since, according to PHP,
On Windows, both slash (/) and backslash (\) are used as directory separator character. In other environments, it is the forward slash (/).

Let's just remove all backslashes from the function and stick with only using slashes (which should then work in all environments).

This needs testing in Windows (which I cannot do since I do not have access to a Windows computer). For this block of code to get run it'll have to be a new installation or one where you delete the file_temporary_path variable.

Wait, isn't this fix backwards? The errors occur on Mac, not Windows.

Incidentally, here's a seemingly related error I got when trying to change header colors on Bartik (Appearance -> Settings (or Bartik):

    * Warning: file_put_contents(temporary:///.htaccess) [function.file-put-contents]: failed to open stream: "DrupalTemporaryStreamWrapper::stream_open" call failed in file_create_htaccess() (line 507 of /Users/tomgeller/Sites/2trees/includes/file.inc).
    * Warning: file_put_contents(temporary://fileB0MrE9) [function.file-put-contents]: failed to open stream: "DrupalTemporaryStreamWrapper::stream_open" call failed in file_unmanaged_save_data() (line 1847 of /Users/tomgeller/Sites/2trees/includes/file.inc).
    * The file could not be created.

The original post referenced using a Windows box, so that's what I've been working from. The problem problem was the mixing of / and \ in the temporary directory path. That is, sites/default/files\tmp is not a valid temporary directory path, but sites/default/files/tmp is valid. The patch in #5 solves this problem.

If you are experiencing a similar error on a Macintosh setup, we'll need some more information to debug it (like what the tmp directory path is set to, are there any messages on the status page, etc).

Lastly, the error you cite in #6 isn't obviously directly relevant, so I suggest filing another issue so it doesn't get lost in this issue.

both of you are reach same problem ??
both set tmp dir to "sites/default/file\tmp" or you are face tmp dir problem only ??

you are manually set the tmp dir that never jump into the loop #4, and $path_delimiter is needed.
if you are in windows, you set your public file path to C:\\windows\file, so you tmp path will be C:\\windows\file\tmp.

we don't output something like C:\\windows\file/tmp to users. it's horrible.

droplet: You are probably correct that if the patch needs a bit of work. I don't have access to a windows machine, which complicates things at the moment.

I guess, given your concerns with Windows which are probably valid, that we should then use the following workflow:

1. Collect paths, runing strtr to convert all DIRECTORY_SEPARATOR to '/'.
2. Compute which directory should be the tmp directory
3. (Maybe) Convert from '/' back to DIRECTORY_SEPARATOR.

Does this seem reasonable?

@bfroehle, thanks for your help. I've done a little more poking around, and think the issues I'm having might be related, but I'm not sure yet.

In short: The site was created on Windows. I've migrated it to Mac, and have been having problems. I just discovered that the Temporary directory (at admin/config/media/file-system) was set as c:\windows\temp (!).

I have no idea why that happened: I never touched that setting. Any ideas? Is this related?

Thanks,

--Tom

@tgeller,

"The site was created on Windows. I've migrated it to Mac"

Drupal won't change settings for you when it moving form platform A to B. Just change it to right path yourself :)

Thanks, @droplet. The issue wasn't about Drupal *changing* the setting; I was hoping that Drupal would make the setting at runtime, rather than the current situation.

Here's what's going on. I'm producing a series of Drupal database exports that I'd like to run on both Mac and Windows. (These are instructional files for my lynda.com video courses.) The best situation would be for me to leave the "Temporary files" field blank, and have it stay blank until I can export the database. But Drupal makes the path calculation immediately upon save.

I can see why that is, but maybe one of you could help me get around it. Is there a value or line I could remove from my database (after export) that would force the correct value to be filled in on the environment of anyone who uses it?

Thanks!

I think I figured it out! The value is stored in the variable table, field name = 'file_temporary_path'. But there's also a change to the cache_bootstrap table. One has to edit both of those values to make it work.

Sorry for the diversion.

tgeller: Glad to hear you figured it out!

The attached patch addresses the issue faced by the original poster, namely the code

$temporary_directory = variable_get('file_public_path', conf_path() . '/files') . $path_delimiter . 'tmp';

is not generically safe to use in Windows since the file_public_path variable may contain either backslashes or forward slashes. PHP is smart enough to allow using either backslashes or forward slashes in paths, but does not seem to allow a path to use a combination of those.

The patch takes the output from above and sanitizes it to convert all backslashes to forward slashes, much like what is done in includes/file.inc.

I'd appreciate some testing on Windows, especially by the original poster (benjamin.wss) since he can trigger this code pathway on his setup. (Apply the patch and try a fresh install of Drupal -- ensure that the temporary path is sane and you have basic functionality with upgrading modules).

tagging IIS.
I'm pretty sure PHP5.2 + Windows + Apache is okay with slash (/) and backslash (\) combination.

and it needs to fix drupal conf checks if there is something wrong (beucase drupal has passed checks in #1 post)

I'm quite new to Drupal and still very much finding my way so forgive me for asking silly questions. I installed a version 6 some time ago at my providers server. It worked OK but i did not actually develop the site any further. When I got to really building I noticed the new version and decided to upgrade. That created a giant mess. So I completely cleared the database and threw away all Drupal files on the server. And made a brand new installation of 7.0.

From the very start I get this message:
* Warning: file_put_contents(temporary://fil39A7.tmp): failed to open stream: "DrupalTemporaryStreamWrapper::stream_open" call failed in file_unmanaged_save_data() (regel 1847 van D:\www\gerardcappers.nl\www\includes\file.inc).
* Het bestand kon niet aangemaakt worden.
* Warning: file_put_contents(temporary://fil39A8.tmp): failed to open stream: "DrupalTemporaryStreamWrapper::stream_open" call failed in file_unmanaged_save_data() (regel 1847 van D:\www\gerardcappers.nl\www\includes\file.inc).
* Het bestand kon niet aangemaakt worden.

The filenames "fil39A7.tmp" go one step up every time I refresh the page. You can try it for yourself on www.gerardcappers.nl.

I contacted the provider (IIS - Vevida.nl) and they cheked all authorisations. Everything OK......

It's a blocking issue that was reported form upgrades, but my installation is brand new. And there seems to be no way around this. What can I do besides downgrading to 6 again or just waiting and trying Drupal in april again?

This bugreport has a patch and is marked "needs review". It should remain so, unless you review the patch and deem it does not solve the problem reported originally in the issue.

Please post in the forum for getting support (vs fixing the bug/reviewing the patch).

Putting this back to major.

In comment #18 I reported an ongoing problem. Heine (#19) asked me to help reviewing. I'd like to, but I have no direct acces to the Windows server where the site is hosted.
What I can do is manually change the code in the file ../includes/file.inc which seems to be the bad guy. Can someone help me to extract the changes from the patch file or send them to me?

capersg: See http://drupal.org/patch/apply.

I checked the "apply patches" page already - of course. I'm "old-school" and always try to read the manual first:-). But applying a patch through a *.patch file as described in this page requires access to the root of a server as far as I can see. And that's exactly what I can't do: the server is at my providers datawarehouse......
Manual recoding and uploading is all I can do at this moment. I tried to decipher the patch file and tested another file.inc whith lines replaced, but that didn't work.
I'm trying to set up a testserver on my own PC, but failed to get it running so far. To be continued......

main problem here is backslash (\) do not work in Windows + IIS. @cappersg, you can simply test it before actually apply patch.

IMO, keeps unpatch code is better than force it to slash (/).

@droplet: what should I do? I'm not that good in reading code :-)

@cappersg,

go to admin/config/media/file-system and check what your "Temporary directory" and "Public file system path" is. make sure all of them are writable.

tell us if your pattern like this and failed:
http://i.imgur.com/KQhvq.jpg

I added a screenshot of the file-system settings. The sites/default/files directory is read/write/execute: provider confirms this, though it seems to work a little different for Windows than the "777" for linux etc....
The provider also says that d:/tmp the standard temp directory is.

I tested changing to d:\tmp: no success....

@cappersg: There's your problem! Change "d:/tmp" to "/tmp".

P.S. My advice might be wrong: I don't usually use Windows. But it's worth a try.

P.P.S. Nederlander, hé? ;)

@tgeller: almost BINGO for the solution, full bingo about being Dutch!!

I followed your advice but /tmp didn't work. I decided to try some other options. \tmp didn't work either, but just "tmp" does the trick!!! Screenshot added. So the way of thinking was perfectly OK!

I hesitate to close the subject: for me it's solved but I think some more testing should be done. But it's certainly a simple solution worth trying for others.

Ah, yes, the path is relative to your Drupal installation. I think if you put in a leading slash, Drupal tries to reach the root directory if your computer -- which it can't actually access. But I'm not sure about that.

Anyway, congratulations for your success! De groet,

--Tom

#15: 1019470-15-sanitize_path_to_use_slash.patch queued for re-testing.

Had the same issue. I tried the solution by cappersg. Worked like a charm! Thanks a lot!

Hello,

A fresh install of Drupal7.2 sets the temp dir also to sites/default/files\tmp, after corrected to sites/default/files/tmp all is well.
I have everything on localhost, so feel free to ask me to do any testing (if any needed).
Specs: Drupal7.2, Windows 7 x64 SP1, IIS7.5, PHP5.3.6

Just tested #15 1019470-15-sanitize_path_to_use_slash.patch with a fresh 7.2 install on IIS7.5 and it solves the problem.

#15: 1019470-15-sanitize_path_to_use_slash.patch queued for re-testing.

Re-rolled #15 to correct fuzz; no code changes; marking RTBC based on inspection of code and multiple reported successes.

Hm. It sounds like we need an upgrade path for this? I see a lot of people talking about having to manually twiddle their temp directory variable.

The net change of this patch is this:

If a Windows user sets their files directory to sites/mysite/files, then the default temporary directory would become sites/mysite/files/tmp rather than sites/mysite/files\tmp Conversely, if the Windows user set their files directory to C:\WWW\Files, then the default temporary directory would become C:/WWW/Files/tmp, whereas the old code would choose the functionally equivalent C:\WWW\Files\tmp.

Without this patch, a path may be generated that contains both forward-slash / and backslash \ characters. The realpath() function will return FALSE if its argument contains both kinds of slashes.

This patch has no effect on users who have explicitly set their temporary directory, nor does it make a functionally different choice in the cases where the old code worked. It only fixes an edge case where the old code failed.

So I don't see where any upgrade path is necessary. The "people talking about having to manually twiddle their temp directory variable" were discussing a work-around for the problem. This patch does not conflict with such work-arounds, but it does make them unnecessary.

That's a good explanation to me, the patch looks fine. I do not have a windows box to test on but looks like lots of people reported back. We don't have a windows test bot to write a test for this and it's almost a one-liner. Moving back to RTBC.

Ok, thanks, that explanation makes sense.

However, this patch no longer seems to apply.

Hmm, applied with offset for me, re-roll anyway.

Moving back to RTBC since it's a straight re-roll but please wait for the bot to confirm.

Just a reroll no credits please

Cross post and use #43 if green

Hm. It applies to 8.x but not 7.x. Weird.

Well, committed and pushed #43 to 8.x, but we need a 7.x backport.

Re-rolled for 7.x
EDIT: sorry; clicked on the wrong patch.

This is the right patch.

Awesome, thanks! Committed and pushed to 7.x.

Excellent catch, "anonymous". The message displays as a warning, however, the module still does not load.

I am using Drupal 7.5. I went to Administration -> Reports -> Status Report

Reviewed the Site Parameters and indeed the File System was showing an error. TMP was not defined correctly. I reviewed the folders under my drupal installation and found the TMP folder. Took that full path and entered into the File System -> TMP setting. Problem resolved.

I'm totally stuck and desperate.
I have been reading this post over and over and I need to have some guidelines on how to solves this.
I have moved my site from a windows to a linux server.
I have exactly the same problem as described cannot access the tmp directory from windows c:\tmp drive (not surprising). As I have imported the database and the variable is stored in there.

The trouble Is that I cannot access the admin media setting tab I get a blank screen with the above error. So I guess I need to go to phpmyadmin and modify the variables by hand. I
have found the file_temporary_path but I don't seem to be able to modify the variable it says binary type and invites me to upload a file?
Is there a way out of this deadlock situation ?
Thanks!

I'm still very new to Drupal and the community, and not much of a developer so for what it's worth: have you tried the solution options around #28 in this thread? It's about just modifying some parameters (/, \ of no slash at all) in Drupal itself......

Hi pcoloma, I am stuck exactly where you were in your response (Cannot modify the file_temporary_path in PhpMyAdmin, nor can I access the Drupal Admin console) . Did you ever find a resolution? Any help would be great appreciated. Cheers!

One way of changing a variable is to install the devel module, enable the devel block, and then use the variable editor to edit this variable.

This did not work for me, but in my case the file_temporary_path variable was overridden in the settings.php file by another administrator to a value that worked before the site was moved.

If your screen is totally blank then the memory_limit in your php.ini file on the new site might be too low, but it sounds like you are not getting totally blank screen, rather you have error messages.

I discovered another possible cause. I was experiencing similar errors but it turns out it was because PHP "safe_mode" was turned on in my server setup. Simple mistake but it took many hours to figure it out.

I agree that a warning should appear in the Status Report if PHP "safe_mode" is detected as mentioned at http://drupal.org/node/959644 as this may cause other problems as well.

Just an update for anyone using a prebuilt LAMP install in Windows... It seems that the fix is actually as simple as creating a tmp directory in C:\ (i.e. C:\tmp) as the temp directory according to such programs as xampp is C:\xampp\tmp

Hope this helps!

to solve this problem just create a new folder named "tmp" in sites/default/files/

Regards:
Yasir Ali
Islamabad, Pakistan

61 does not work for me regarding setting up a tmp folder

In my case, I have to create a 'Temp' folder in the D:. My PHP, Apache and D7 foldres are located in D: as well.

I Had this problem after uploading the site from the my local drive. I wasn't able to install new modules.
The fix was to change the location of my temporary directory.
It was pointing to C:\xampp\tmp
changed it to : /data/tmp -- or leave it blank and save it. Drupal will fill it in for you.

Hi,

I just did a new first-time install of Drupal 7.14 on my Windows Server 2008 machine. I ran into the same error. I tried everything you guys mentioned here, but to no avail. I created the tmp-folder under files, but this didn't help. I finally resorted to giving "everyone" change-rights to the includes-folder and the sites\default\files folder and everything below. the folders sites and sites\default remain read-only. This was not the complete solution, but now the system was able to write into those folders. The other thing i did, was rename the file.inc in the includes-folder to file.inc.old and then refresh the web-page a few times. (i was logged into the console of drupal, with the filesystem config on the screen) This generated a long list of errors and i finally ended up with a completely blank screen. At this point, i decided to restore the file.inc to it's former name and do another refresh. To my big surprise, all errors had vanished and everything now works fine!

Hope this helps,

poktor

#61 worked for me by creating a tmp folder in sites/websitefolder/files/

Issues such as this are used to fix actual bugs in Drupal core, not a place to add support requests. Please use the support forum.

If you want to provide documentation on a subject, please add to the Installation Guide or Troubleshooting FAQ.

Hy,
I was working local and i had the same error but by going to Administration » Configuration » Media>>
File system and saving again the configuration it worked.

I hope it works for you to

Hey roxana04, your recommendation worked perfectly! Thank you!!!! -Frederico Garza

#68 worked for me too

#68 worked for me too

Hello All,
The solution for this issue is:
1. Create "tmp" directory in "sites/default/file".
2. Give appropriate permissions to the folder.
3. Go to "admin/config/media/file-system" & save the form again ensuring "/tmp" folder as a "http:///admin/config/media/file-system"

Thanks

Well actually I only had to edit admin/config/media/file-system to point at -simply- /tmp out of the public root of the server... also recommended by the drupal docs: not to have the directory inside of public_html directory in your server.

Thanks, this thread helped me solve it.

Nico

#68 worked perfect!! Thanks a lot.