By brashquido on

Hi All,

A few weeks ago I changed the download method in Drupal from Private to Public as using the Private method was causing performance issues. I tested all my files after making the change and they all worked, and I also tested uploading files which also appeared to work as far as attaching a file (using the upload module). However, I didn't actually submit any new uploads at the time.

Since then I've needed to upload new files, and everything goes fine until I click on the submit button where I am presented with this error;

The selected file could not be copied, because no file by that name exists. Please check that you supplied the correct filename.

I've seen this error all over the Drupal forums, but so far no solution. I've also tried setting the Drupal download method back to Private, however the error remains. I also added the web user to the administrative group to be sure it wasn't a permissions issue. Any ideas?

⋅ Categories: Drupal 5.x

Comments

cog.rusty’s picture

cog.rusty commented

Check the admin/logs/status page to see if Drupal complains about the files or the temp directory. Also give us some specific paths. Are there any paths in the error message? What are the paths of the files and the temp directory in admin/settings/file-system? Any warning when you save that page?

Also check the admin/logs/watchdog page for any errors after trying to upload something.

brashquido’s picture

brashquido commented

Thanks for the reply.

Drupal status report says that the file system is writable, and there are no entries in the Drupal log, or the PHP log for that matter. Initially I was getting errors about open_basedir being in effect and was indicating it was trying to move a file from the Windows temp directory, however I disabled that directive and now nothing shows. The weird thing about this is that everything PHP/Drupal should need to write (Drupal temp & files directory, PHP upload_tmp_dir directory) to is inside the directory specified in open_basedir, so why is Drupal trying to access the Windows temp directory?

I have checked and rechecked permissions, and as I've run the web user as an administrator with full permissions to everywhere on the server this should not be the issue. The Drupal files directory is inside the Drupal root, however the Drupal temp directory is outside of the root. I tried moving the Drupal temp directory to inside the Drupal files directory (so I knew it would be writable), however that didn't work either.

The real confusing thing for me is that changing back to the Private download method doesn't fix it. What does Drupal do exactly when you change download methods?

----------------
Dominic Ryan
www.iis-aid.com

cog.rusty’s picture

cog.rusty commented

As far as I know, the main thing which the private download method does is create virtual paths named system/files/filename and serves the files from there, never using the real file path.

brashquido’s picture

brashquido commented

Ok, thanks. I've used the Process Monitor tool from Systernals to follow the file upload progress in Drupal from start to finish, and Drupal is doing some really, really weird things. I can see the php-cgi proccess creating the temp file in the PHP upload directory which seems to load fine. However from what I can see the php-cgi process then tries to move the file to the Windows TEMP directory as another temp file, and once that completes the php-cgi process reports the file I'm trying to upload as non existant.

This will explain why I was getting the errors that open_basedir was in effect. Why on earth does Drupal try and write to the Windows TEMP directory? It is NOT a permissions issue, as stated I've run the IIS user as an administrator with the worker process as Local System which gives Drupal full access to the system.

I've tested a number of other PHP apps, and this behaviour is NOT present. Even using my Drupal DB from before I converted from Private to Public downloads does not do this. This is Drupal, and I suspect there is something deep in the code which is causing Drupal to try and write to the Windows TEMP directory as some sort of fall back.

I think this is going to need the help of someone with quite initmate knowledge of Drupal to solve. So hopefully they see this. If you want to have a look at the Process Monitor log file, it can be downloaded from below.

http://beta.iis-aid.com/logfile.csv

----------------
Dominic Ryan
www.iis-aid.com

cog.rusty’s picture

cog.rusty commented

This is interesting. Looking at the includes/file.inc file where all this stuff is (http://api.drupal.org/api/file/includes/file.inc/5), there is only one place mentioning c:\windows\tmp, this function:

http://api.drupal.org/api/function/file_directory_temp/5

But from what I can see, it should just return Drupal's temp directory from the variables table if it existed. So, for some reason it doesn't find it and it enters in a strange hunt, first trying to find php's temp directory, then either c:\windows\tmp or /tmp, and finally files/tmp.

This one has a comment in the fifth line, about needing refactoring:

http://api.drupal.org/api/function/file_save_upload/5

And this one, mentioned in the previous comment, is the one which tries to take some precautions for open_basedir by "moving uploaded files from php's upload_tmp_dir to Drupal's file temp"

http://api.drupal.org/api/function/file_check_upload/5

brashquido’s picture

brashquido commented

Insteresting. So it would seem this "weirdness" might be a side effect of a larger issue I have with my site. I have checked the variables table and the path is definately correct. I have also tested uploading files after changing between private and public on a fresh install of Drupal 5.7 (which I'm still using for the moment) and it works perfectly.

At this stage I think the fact that Drupal is going on a wild goose chase is secondary to the fact that it can't find my files directory. Looks like I'll have to do some digging.

----------------
Dominic Ryan
www.iis-aid.com

brashquido’s picture

brashquido commented

This is definately an issue with the upload module in the core as I can still upload fine using IMCE, etc. Not sure why, but something has broken it on my site.
----------------
Dominic Ryan
www.iis-aid.com

cog.rusty’s picture

cog.rusty commented

Try a little "quick and dirty debugging" (http://www.lullabot.com/articles/quick_and_dirty_debugging) using the drupal_set_message() function (http://api.drupal.org/api/function/drupal_set_message/5).

In the functions in includes/file.inc, try to set a message about what variable or file it was looking for, what it found and couldn't open, what it didn't find, what it decided to use etc.

brashquido’s picture

brashquido commented

Thanks so much for your help here Cog. Unfortunately my PHP skills are not at a level to be able to do this, and as I'm on the road at present I don't have the time to spend on it to get them there. This issue IS crippling my site though, so I think I'll just have to offer it as a paid job to fix it...

----------------
Dominic Ryan
www.iis-aid.com

xjessie007’s picture

xjessie007 commented

I probably won't say much new, but I just found out about changing the download setting too that it probably is a major thing. See here:
http://drupal.org/node/22240

They say: "If you change your settings at a later date, all download urls will change, therefore it's best to plan ahead when you set your drupal site up and think carefully about whether you'll need to restrict file downloads."

I am thinking about changing this setting from private to public because I need to have it set to public in order for the Aggregate and compress css files functionality to work. Does anyone else has problems with switching from Private to Public? I am just thinking that if making the change should break my site, I probably just pass on the Aggregation functionality, so I was eager to hear what experience others have had.

Does anyone know about any good process to make this change? Perhaps turn off friendly URLs first and then make the change?

Thanks.

---------
www.Maxi-Pedia.com Maxi-Pedia: Your resource for finance and IT!
www.Maxi-Pedia.com/forum Maxi-Pedia Forum: Your place to discuss finance and IT!
www.finance-management.cz Central European Center for Finance and Management

cog.rusty’s picture

cog.rusty commented

There are always problems with that change, that is why it is discouraged after having uploaded files.

In case your problem is different from brashquido's, check the paths of the existing files in the 'files' table in the database in case you have changed the path when settings "private". These paths contain the real paths used for the uploads, but Drupal serves the private files by using virtual "system/files/filename" paths.