If you install Image and Image Attach on 6.4 on IIS, and try to attach an image, you get an error to the effect that the file can't be uploaded because only GIF, JPG, and PNG files are supported. This seems to stem from a problem with the image_get_info function in image.inc, which incorrectly returns FALSE when the image file in question has just been uploaded (e.g., via Image Attach) and is in the WINDOWS/temp directory.

Changing line 117 from:
if (!is_file($file)) {
to:
if (!is_file($file) && !is_uploaded_file($file)) {
seems to fix it.

I don't know if this qualifies as a bug in image.inc, or if it should be regarded instead as a bug in the third-party modules, but it seems to me that it is really a bug in image.inc w/r/t IIS.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

chasz’s picture

subscribe to this

i use IIS but havent used uploading fields yet

SuperContraXTC’s picture

I kept getting the same error message when trying to upload an image.

After I changed

Changing line 117 from:
if (!is_file($file)) {
to:
if (!is_file($file) && !is_uploaded_file($file)) {

it solved the problem. Thanks for the solution.

s_oneill’s picture

I have the same problem and have fixed it with the above suggested hack.

This is not a durable solution though.

jphoude’s picture

I can also confirm this on my installation of Drupal 6.9. The patch posted in comment #2 fixed the problem.

I'm using PHP 5.2.5 / IIS 6.0

mion’s picture

I have the same problem with uploading the images. The comment #2 did not solve the problem.

svanimpe’s picture

Having the same problem, and #the patch in 2 did not solve it. Running PHP 5.1.2 / IIS 6.0. Any help greatly appreciated!

zbricoleur’s picture

Couple of things I would check:

1) Settings at Site Configuration > File System. If Drupal can't write to the temp directory specified there, you will get an error either similar to this or exactly like it (can't remember). If you are on Windows, you'd better make a 'temp' directory inside your 'files' directory, because Drupal won't be allowed to use windows/tmp. Fixing this setting is often all it takes.

2) If (1) doesn't do it, check that permissions are set correctly on the files folder and the temp folder. Drupal needs read/write permission there.

svanimpe’s picture

Hi, thanks for your time.

the directories specified are sites/default/temp and sites/default/files. Both are set to 755 but I don't have access to the server so I can't see who owns it. I've asked for a telnet login, waiting for a reply.

I'm a bit confused about the server being indicated as IIS while the path at the server indicates that we're on a cygwin virtual server. But I'm very much a newbie with webservers, php and drupal, so that is probably just me still trying to find my way.

svanimpe’s picture

Hello again,

We've been able to check, and the permissions for the files and temp folders are set correctly. The server administrator has tested with a different, simple uploading form and this works, confirming that the error lies within the Drupal installation. I have tried may modules, all give the same error (Image, Image Upload, IMCE, ...). Maybe the problem lies with Drupals upload function?

zbricoleur’s picture

By 'correctly,' do you mean 755? Because that won't work. The anonymous user has to have write privileges.

svanimpe’s picture

It's an IIS server, so there's no 755. The server admin confirmed that the webserver has write privileges; I'm not sure if that means anonymous has write privileges. I'll contact her again.

PS Sorry about taking so long to reply each time, unfortunately webmastering is only a minor part all the things I have to do...

madlee’s picture

Version: 6.4 » 6.12

I was having this issue with 6.12 on IIS 6.

Setting the file system path for the temp directory didn't seem to fix it. It seems like ImageField still wants to use the windows temp folder. Setting IUSR permissions on the windows temp directory seems to fix it.

klas.lundberg’s picture

Version: 6.12 » 6.15

I'm having this issue on Drupal 6.15 Microsoft-IIS/6.0

smyleeface’s picture

I remember having problems with the temp directories, can't remember what I was working on; I think it was upload...

Anyway, in the beginning of the Drupal installation I changed the Drupal temp directory to another directory because I didn't want to use the default windows temp directory.

To build on what madlee said, I too gave in and also set IUSR permissions on the windows temp directory. I have a theory that it was using the PHP temp directory setting as that happened to be the windows temp folder.

Also, the permissions that are set in the windows temp directory are carried over when the file gets "moved" to the files directory. That was giving me problems as well.

Going back to the original topic of this thread, the fixed worked for me and haven't had any problems with it. :)

earthday47’s picture

After exhausting all possibilities, this fixed worked for me.
IIS 6, Drupal 6.16, ImageField 6.x-3.2.

Now, how do we get this fixed in core?

sreynen’s picture

Status: Active » Needs review
FileSize
522 bytes

The attached patch simply applies the code change described by zbricoleur.

Status: Needs review » Needs work

The last submitted patch, iis_file.patch, failed testing.

zbricoleur’s picture

OK, here's my attempt at a patch...

sreynen’s picture

Status: Needs work » Needs review

I'm changing the status to "needs review" to get automated testing on the patch.

Status: Needs review » Needs work

The last submitted patch, image.inc-iis_bug-307636-18.patch, failed testing.

zbricoleur’s picture

This is a ridiculously simple patch (1 line!) that has worked just fine on several sites for years now. So, I must not be creating the patch file properly. Where do I go to learn what I'm doing wrong?

sreynen’s picture

Version: 6.15 » 6.17

@zbricoleur it looks like the issue with your patch (and mine) is just that it's against a different version of Drupal (6.17?) than this thread is against (6.15). This just stops the automated tests from running. I'm going to try to retesting against 6.17.

sreynen’s picture

Status: Needs work » Needs review

#18: image.inc-iis_bug-307636-18.patch queued for re-testing.

Status: Needs review » Needs work

The last submitted patch, image.inc-iis_bug-307636-18.patch, failed testing.

sreynen’s picture

Version: 6.17 » 6.x-dev

Hmm. 6.x-dev?

sreynen’s picture

Status: Needs work » Needs review

#18: image.inc-iis_bug-307636-18.patch queued for re-testing.

zbricoleur’s picture

No, sorry, it's against what I thought was the latest 7.x-dev. I thought that's what you were supposed to do... Like I said, I'm pretty unclear about the process.

Anonymous’s picture

Have we had a successful patch for this yet???

http://drupal.org/node/307636#comment-1144383 works.

Cheers,

S

shv_rk’s picture

cant find image.inc file! :(

Status: Needs review » Needs work

The last submitted patch, image.inc-iis_bug-307636-18.patch, failed testing.

allanp’s picture

I have tried the fix and temp directory was set in default/files during installation.
This did not solve the problem.
Has anyone found a solution?

Drupal 6.19
IIS 7.0

quicksketch’s picture

Title: problem with image.inc on IIS » image_get_info() fails on IIS on new uploads
Version: 6.x-dev » 7.x-dev
Priority: Normal » Major
Status: Needs work » Needs review
FileSize
508 bytes
521 bytes

So this issue has been stuck in limbo for a long time mostly because very few Drupal core devs use Windows and nearly none use IIS for hosting their sites. However this is obviously plaguing quite a few IIS users out there, here are similar issue where users have all used the same fix with success:

#547814: is_file() fails on uploaded images on IIS
#419734: supported file types return - The file is not a known image format
http://drupal.org/node/301454

In short, IIS doesn't return TRUE for is_file() on newly uploaded files (unlike Apache servers), but it does return TRUE for is_uploaded_file(). This problem prevents uploading of files into any ImageField in Drupal 6, and when using the Image field provided on the Article content type by default in Drupal 7.

For users in this queue, we always need to apply patches to the latest in-development version of Drupal first, then backport to the current version. So we'll fix D7 first and then get this added to Drupal 6.

This patch is trivial, if it passes the bot this should be RTBC'd.

quicksketch’s picture

Status: Needs review » Reviewed & tested by the community

The comments above of users that have applied the previous patches confirm that this solution works (#2, #3, #4, #14, and #15), the previous patches just weren't rolled correctly to work with testbot. Considering this is the exact same patch just rolled with the right path, I'm marking RTBC.

webchick’s picture

This doesn't seem like it would hurt anything, but I'd love final confirmation from one of the above posters to be sure.

If no responses within ~24 hours, I'll go ahead and commit this anyway.

webchick’s picture

Version: 7.x-dev » 6.x-dev

Ok then. Committed to HEAD.

Marking back to 6.x.

quicksketch’s picture

Sweet, thanks webchick. This should also be applied to Drupal 6, the D6 patch is in #32.

Gábor Hojtsy’s picture

Version: 6.x-dev » 7.x-dev
Priority: Major » Minor
Status: Reviewed & tested by the community » Needs work

Thanks, committed to Drupal 6! I'd however suggest we add a comment to both D6 and D7 so this "superfluous code" is not optimized out sometime soon :)

yas’s picture

Status: Needs work » Needs review

Let me report as follows in Drupal 6.20:

I upgraded our site to Drupal 6.20, and I found that Drupal 6.20 with the latest version of SimpleTest reports the error (warning / Notice) shown below:

Test image_get_info() failed: Undefined variable: filepath

I checked image_get_info() function in image.inc file and found that actually $filepath is not defined or initialized. I needed to revert that part to #16: iis_file.patch in order to suppress the error / warning.

quicksketch’s picture

Version: 7.x-dev » 6.x-dev

Holy cow! Thanks yas. The variable name is "$filepath" in D7 but "$file" in D6. I don't know how I missed that. Sorry Gábor, now we've introduced a new bug without fixing the old one. Here's a patch for D6 that adds the comment (if desired) but more importantly fixes the name of the variable.

quicksketch’s picture

FileSize
738 bytes

Right, the patch.

Status: Needs review » Needs work

The last submitted patch, image_iis6.patch, failed testing.

Gábor Hojtsy’s picture

Status: Needs work » Needs review

Well, it is at least not worse for anybody, right, since !is_uploaded_file($unknown) will just return TRUE at all times, as if this was not part of the && expression? So looks like we just did not manage to fix it but did not break it much further (except adding a notice of an undefined variable). Much better then say breaking this function for all users.

roper.’s picture

Can we please get this into D6? I'm working on a client's site who's stuck with IIS and it's giving me nothing but headaches. This patch is a necessity.

Thanks!

joelstein’s picture

Status: Needs review » Reviewed & tested by the community

#40 works for me (I was getting lots of these PHP notices in my logs).

Peng.Pif’s picture

+ 1. Am also stuck with using IIS. Thanks all

Heine’s picture

Status: Reviewed & tested by the community » Needs work

WHOA!

Can we please do some analysis first? This is likely either a permission problem or a bug in PHP.

For starters, I cannot reproduce the failure of "is_file" in this scenario. Only realpath is giving me trouble on PHP 5.3.4.

For those who can repro, please use procmon to monitor file access. Enable capture, upload a file that should give trouble, then filter on process name and path:

- Process name is likely php-cgi if you use fastcgi.
- Filter path with "begins with" and "c:\Windows\Temp"

then post here.

chrsc’s picture

Version: 6.x-dev » 6.20

Current Drupal 6.20 includes/image.inc line 117:
if (!is_file($file) && !is_uploaded_file($filepath))
should be:
if (!is_file($file) && !is_uploaded_file($file))

I need to patch this each time I upgrade the drupal core on IIS.

quicksketch’s picture

Status: Needs work » Reviewed & tested by the community

@Heine: The only thing remaining in this issue is literally a variable typo. The variable name is $file, not $filepath.

Heine’s picture

I argue that the fix is bogus and/or the cause not investigated sufficiently.

zbricoleur’s picture

This fix is an additional 27 characters of code. It's been almost 2 1/2 years since this issue was originally posted. Even if it's "bogus," is it really worth wrangling about 27 characters at this point?

quicksketch’s picture

I argue that the fix is bogus and/or the cause not investigated sufficiently.

This problem definitely existed in some versions of PHP, most likely even in the most recent releases because no one has ever solved the problem over on the PHP end (probably because they care about as much about Windows as Drupal does... not much). The last confirmed report in this issue was against 5.2.8. In any case, enough versions of PHP are affected for Windows that this should be accommodated for. http://bugs.php.net/bug.php?id=38308

Gábor Hojtsy’s picture

Status: Reviewed & tested by the community » Fixed

Committed and pushed, thanks.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

kcorum’s picture

Priority: Minor » Critical

We are having the same issue:
IIS7.5
PHP 5.3.8
Drupal 6.22
The patch listed does not fix the issue for us. File permissions have been checked and are correct. The default user that is setup during install, can upload files with no problems, but all other users fail (even if given all perms to everything) with the error:
The selected file could not be uploaded. Only files with the following extensions are allowed: jpg jpeg gif png txt doc xls pdf ppt pps odt ods odp docx.
There has to be a fix for this. Does anyone have anything else we can try?
Thanks.

Heine’s picture

kcorum, from #46:

For those who can repro, please use procmon to monitor file access. Enable capture, upload a file that should give trouble, then filter on process name and path:

- Process name is likely php-cgi if you use fastcgi.
- Filter path with "begins with" and "c:\Windows\Temp"

then post here.

You may need to adapt the path.