I was having a lot of trouble uploading images and repeatedly getting the error:

Warning: filesize(): stat failed for public://image.jpg in file_save() (line 575 of /home/patcms/public_html/includes/file.inc)

When I logged into my server (Ubuntu 10) I went to the directories that I had setup on the admin/config/media/file-system screen. Here in the "~/public_html/sites/default/files" directory, I could see sub-directories, but I didn't see any of the files I had tried (& failed) to upload.

However I did notice that files were being uploaded to "~/public_html/public:" (with the colon and everything).

Based on this I created a "~/public_html/private" directory, and configured that on the admin/config/media/file-system screen. After switching my content type to put images in private storage everything worked fine.


zabelc’s picture

Title: Uploaded files written to "~/public_html/public:" » Unable to upload files: writing to "~/public_html/public:" and "~/public_html/private:"
Priority: Normal » Major

After further experimentation I've discovered that the private file work-around only works for the FIRST node save.

Every time I try to save a second node I get a similar error:

Warning: filesize(): stat failed for private://Banner3.jpg in file_save() (line 575 of /home/patcms/public_html/includes/file.inc).

Effectively this means that I can't upload any files.

I'm using Drupal 7, and filefield_paths 7.x-1.x-dev (though I haven't applied a file field to this node), and token 7.x-1.0-beta1. I'm on Ubuntu 10 with PHP 5.3

bfroehle’s picture

What are your settings in admin/config/media/file-system ?

In your PHP settings (i.e., admin/reports/status/php), what are the values of safe_mode and open_basedir ?

zabelc’s picture


Public file system path = sites/default/files
Private file system path = private
Temporary directory = /tmp
Default download method = Public local files served by the webserver

PHP Version 5.3.2-1ubuntu4.5

Directive Local Value Master Value
safe_mode Off Off
safe_mode_exec_dir no value no value
safe_mode_gid Off Off
safe_mode_include_dir no value no value
open_basedir no value no value
Pancho’s picture

Project: Drupal core » File (Field) Paths
Version: 7.0 » 7.x-1.x-dev
Component: file system » Code
Priority: Major » Critical

I had the same error today and nearly freaked out because I couldn't find what was wrong there.
Finally, I found out that something had created a directory named "public:" (with colon) into Drupal's root directory.

I'm not completely sure whether it was "filefield_paths" fault, but after zabelc reported the same error with "filefield_paths" installed, it might be the case. Also, the error appeared for the first time some hours after installing "filefield_paths".
Uninstalling "filefield_paths" didn't help however, only removing (or renaming) the stray directory did.

zabelc: Does the error vanish after deleting this stray file?

I'm moving the issue as critical bug to the "filefield_paths" queue for now.

zabelc’s picture

@Pancho, It's been a while since I looked at this but, when I tried to correct the error, I saw some very strange behavior. I seem to recall that after I deleted the "public:" directory it would work one or two times and then stop. The same thing was true when I switched it to private.

At this point, I have a bizarrely kludgy work-around wherein I have a "private" directory that I configured, as well as a "private:" directory which is a symbolic link to the "private" directory. I believe I found one case where the file would be uploaded to "private:" but the system would try to read it out of "private".

a.siebel’s picture

subscribe... i have the same problem

I wanted to edit an node:

* In the upload-form after uploading the filepath ist /sites/default/files/dsc_0478.jpg - There is no image, so it displays no thumbnail and writes in the image_add form: dsc_0478.jpg (0 Bytes).
* I found the picture in the file system in /public:/dsc_0478.png

I have the problem only for some nodes (maybe only in editing screen, but I'm not sure). After creating a new node and adding the picture, the picture was uploaded in bilder/dsc_0478.jpg and there is no problem.

a.siebel’s picture

even after disabling filefield path and changing field to private upload_dir, the file is uploaded in /public: :-/
Maybe it is an d7 core problem?

Ähm... forgot to reload node_add page *g*.

metakel’s picture

After updated to the latest dev (10 July 2011) I found this bug suddenly appears.

When I create content / edit content, I cannot upload any image nor file. The below error was shown:

The specified file public://xxx.jpg could not be copied, because no file by that name exists. Please check that you supplied the correct filename.

After this in my second attempt the below AJAX error is shown:

An AJAX HTTP request terminated abnormally.
Debugging information follows.
Path: /file/ajax/field_img/en/0/form-zxRk0tvm8FMXUbZwI_ZZceHd4fsi_vYddFrPSf836so
StatusText: n/a
The website encountered an unexpected error. Please try again later.    

ReadyState: undefined

(where field_img is my content field name.)

I think this is not related to the transliteration. The files I attempted to upload had just plain English filenames without space, special character and with standard *.png, *.gif and *.jpg as extension.

And as described as #4 above, now I have a newly created "public:" directory under the Drupal root. It contains those files I attempted to upload via the content creation / editing in these few days (after the update of the latest dev).

My PHP version is 5.3.5, with Drupal 7.4 in multisite configuration. The problem exist no matter I set /sites/my-site/files to 0777 or 0775.

I suspect that the problem is that something uploaded the temporarily file to "(Drupal root)/public:/" instead of "public://". So when I clicked "save" for the content, Drupal cannot find the file in "public://" to copy to the appropriate directory.

Revert to 7.x-1.0-alpha1 of this module fixed the problem.

montchr’s picture

I'm having this same problem as well. I've tried deleting directories and changing to a private upload path, but these haven't work. As of now, I've deactivated FileField Paths.

@metakel: Reverting isn't the solution for me - I never used the dev version. I've been running 7.x-1.0-alpha1 since it was released.

metakel’s picture

@montchr: I have just confirmed again from my another Drupal installation that even I had reverted to alpha1, I still can't upload (this is my another installation). And the "public:/" directory was still created during file upload (and the uploaded files were put there). I then try to disable the module, and the bug is still there!

So the culprit is not filefield_path, but I really can't tell which other module caused this.

Is there anyone have any idea what is going on for the "public:/" created at the document root?

h0tw1r3’s picture

** deleted irrelevant comment **

h0tw1r3’s picture

Status: Active » Postponed (maintainer needs more info)

Who wants to share what modules they are using? I'd be happy to take a look, but I can't reproduce.

montchr’s picture

Sorry for the delayed response. Here's all the modules I'm using (I doubt most are relevant but here you go):

Administration Development tools
Autocomplete Deluxe
CTools (all enabled)
Context (all)
Calendar (all except Multiday)
Date (all)
Devel (all)
Font Reference
Hierarchical Select (all except 'Menu')
Imagecache Actions (+ Canvas Actions)
HTML5 Tools
File Entity
IMCE (+ Mkdir)
Media (+ Internet Sources + YouTube)
Video (+ UI + JS)
Backup and Migrate
Better Formats
Comment Notify
Custom Breadcrumbs
Entity API
Entity tokens
Global Redirect
Image resize filter
Menu attributes
Menu Block (+ Export)
Quick Tabs (+ Styles)
Search 404
Secure Pages
Site map
Page Title
Taxonomy Manager
Delta API (+ 'Blocks' + 'Color' + UI)
Omega Tools
External Links
IMCE Wysiwyg API bridge
Views (+ UI)
Views Bulk Operations
Views Galleriffic
Views Infinite Scroll
Views Slideshow (+ Cycle)

Hope that helps...

metakel’s picture

I have too many modules!

admin_language diff ie6nomore oauth translation_helpers
advanced_help ds imagecache_actions openlayers transliteration
auto_nodetitle email imce page_title twitter
backup_migrate entity jcarousel panels variable
beautytips eva languageicons pathauto video
calendar extlink libraries phpmailer video_filter
calendar_tooltips faq location piwik views
captcha features logintoboggan print views_accordion
ckeditor field_group media
colorbox filefield_paths media_youtube references views_fluid_grid
conditional_fields fivestar menu_admin_per_menu rules views_slideshow
contact_forms footermap menu_block seo_checklist views_ticker
context galleria menu_breadcrumb service_links votingapi
css_injector geofield menu_clone site_map webform
ctools globalredirect menu_per_role site_verify xmlsitemap
cumulus gmap migrate strongarm
date google_analytics nice_menus tagadelic
devel i18n nodequeue token
montchr’s picture

@h0tw1r3: Any insights?

h0tw1r3’s picture

@montchr: thanks for the modules list. I'm looking into it in more detail. Will respond back in a few days with a update.

caspervoogt’s picture

Also been experiencing this. Using the Image module with CCK to upload an image into a node. Using public file paths (sites/default/files). Safe mode is off and open_basedir is not set. Should it be? We're on a VPS so it shouldn't matter. Not sure what else to try!

caspervoogt’s picture

My solution was to set the permissions on "public:" to rwx for u only, in other words I removed rwx permissions from group and other. Now it works beautifully. I still don't know why it was even trying to upload anything into public: ... but at least this works.

metakel’s picture

I'd tried to chmod 700 the "public:" directory but I still got:

The specified file public://bj_thumb.jpg could not be copied, because no file by that name exists. Please check that you supplied the correct filename.

But when I chmod 000 it, it works.

I think it is because this directory's owner is www-data, which is the web server itself.

Petr Illek’s picture

I've just run into same problem. One interesting thing is - I've two content types, both with image upload field. On one I got the error, on the second no. When I try to use the image field from the second on the first content type the error showed up. But when I try to use the first image field on the second content type it works (for that content type.

There are only two differences between these two CT, 1) on the first one I have Video field (Video module), on the second I've chosen the image field to have multiple files.

Hope this helps...

montchr’s picture

I know the Video module isn't causing the problem for me at least, since I haven't used any video fields on my site yet.

silkogelman’s picture

I stumbled upon this issue too in this case:
Drupal 7.8
Image field multiple images (unlimited)
filefield_paths latest dev (2011-Jul-26)
Before installing filefield_paths I did not have this issue with the Image field with multiple images.

Found the same issue is running as core issue:
#1069072: Cannot upload files. Warning: filesize() [function.filesize]: stat failed for public://readme.txt in file_save() (line 575 of
Not sure where it belongs.

marcoka’s picture

exactly the same as mentioned #22

silkogelman’s picture

and to confirm:
there was an erroneous public: directory created in the Drupal installation.

govind.maloo’s picture

This is really very huge problem that stuck my project on the time of delivery.

I don't know to solve this but I just change the permission of "public:" folder that is created by drupal 7.X version on every file upload, to '000'.

Now everything is working fine.

Please fix this bug in next version.

h0tw1r3’s picture

Sorry for the very slow reply everyone. I'm currently not on a paid Drupal related project.

s1l, thanks for the info. I am provisioning a new server for my personal sites (one of which is running Drupal 7). Will do a fresh install with just those modules and squash this bug once and for all. It would help if you could briefly document the exacts steps (ie. install drupal "standard profile", activate x y z modules, edit content type, post article, add images, etc) to produce the bug, as I have not been able to yet.

silkogelman’s picture

I am not completely sure about the steps, but from the top of my head:
on a clean Drupal 7 install:
1) add the imagefield (unlimited images) to the Article content type
2) create some content, add multiple images, save
3) then enable the filefield_paths module
4) try 2 again

marcoka’s picture

that is because there is no file written to the disk. that is why thaterror appears. the file object has an uri inside and filesize trys to check, but actually there is no image.

Deciphered’s picture

Can someone confirm this is still an issue with the latest development release?

I haven't tried to reproduce the issue yet, which I will as soon as I've got time, but if someone who is having this issue is able to reproduce quicker than me who's never seen this issue, it would be extremely helpful.


metakel’s picture

It still appears on the last dev, and even on the latest Drupal 7.9.

Deciphered’s picture

Thanks metakel,

I'll try to reproduce this evening.


Deciphered’s picture

Followed the steps from #27 to no avail, worked perfectly fine for me.

I'm guessing it is related to the server environment in some fashion, but if I can't reproduce the issue I certainly can't fix it.

If anyone wants to volunteer access to a server (preferably a sandboxed dev site) with some level of access to the filesystem (SSH, FTP, etc) that can reproduce the issue 100% of the time I would be extremely grateful.

Otherwise there isn't much I can do for the moment.


pmichelazzo’s picture

Hi guys,

I have the same problem but with private:// directory. Every time that I try to put the files inside the private, the same error occurs and I receive this message in my log report:

The specified file private://xxx.png could not be copied to private://images/xxx.png.

spaghetti_code’s picture

Salam everyone,

I ran into this issue using Drupal 7.10 & Filefield_path 7.x.1.0-beta1 after trying the 'retroactive update' function.
was only able to upload again after deleting the new 'public:' folder, disabling and uninstalling ffp in addition to clearing all cache.
re-enabling ffp leads to the problem again, had to delete module and download a fresh copy, seems to work now.

reproduced the problem on a 2. box (squeeze), while the problem and logs are identical, the 'solution' does not work here, ffp creates the 'public:' folder after each upload, and I can just upload again after deleting the file. on the 1. box (lucid) I uploaded several files without problem and just deleting the public: folder didn't do the trick either.

I just forgot to set a custom path in the 1.box, as soon as i did, it behaved just like the 2.

errors (problem and consequential errors):
- The file permissions could not be set on public://yem045kc.jpg.
- Warning: filesize(): stat failed for public://yem045kc.jpg in file_save() (line 573 of /var/www/drupal7/includes/file.inc).
- Unable to generate the derived image located at public://styles/thumbnail/public/yemen045kc.jpg.
- The file public://yem045kc.jpg was not deleted, because it does not exist.

pacproduct’s picture

Status: Postponed (maintainer needs more info) » Needs review


We're experiencing the same issue on our project, and we found out what is wrong in our case:
When the Drupal root directory is writable by the web server, saving a node containing a picture creates this folder "public:" in Drupal's root folder. Once this folder created, any further picture upload fails, raising errors like "Warning: filesize(): stat failed for public://image.jpg in file_save()".

That happens because function "filefield_paths_filefield_paths_process_file()" uses the following:

    // Finalize files if necessary.
    $dirname = dirname($file['filepath']['new']);

PHP function "dirname()" works fine if the tested path is for instance: "public://images/my_pic.jpg". That would return "public://images". But if the tested path is only "public://my_pic.jpg", dirname() returns "public:" only.
And that triggers the issue exposed here.

On our project, replacing the "dirname()" by drupal_dirname()" fixes the problem.
Like this:

    // Finalize files if necessary.
    $dirname = drupal_dirname($file['filepath']['new']);

Could someone confirm that solves the problem for them too?

Deciphered’s picture

Thanks pacproduct, I appreciate your research, it looks like I should be able to confirm and resolve the issue shortly.

Deciphered’s picture

Status: Needs review » Fixed

I still wasn't able to reproduce the error, however based on the information from pacproduct I was able to see that there was an issue and that it's most likely related to the error everyones having here so I am confident enough with the fix to mark this issue as fixed.

spaghetti_code’s picture

pacproduct solution worked for me (also the missing $ is already reported and fixed), thx gentlemen.

Status: Fixed » Closed (fixed)

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

czigor’s picture

Status: Closed (fixed) » Postponed (maintainer needs more info)

I had this issue after upgrading from D7.9 to D7.12 and upgrading FFP from alpha1 to latest dev. (I don't know which of the two is responsible for this behavior). I could only "solve" it by removing FFP.

I have a custom content type with an image field in it.

I don't know how to reproduce.

Interestingly even after the upgrades it's working on localhost, but not on a server with safe_mode.

As I don't know how to reproduce, but the problem definitely exists, I mark this as postponed(maintainer needs more info).

aliaric’s picture

Yes, i met same problem with my custom module. I one situation it works fine. In another - problem appears...

mncrff’s picture

I was having this exact issue. If I created a content-type with the filefield_paths module active, whenever I would create content of that content-type and upload a file, it would create a public folder in the root and then store the uploaded file there. I just deleted my content-type and the public folder and then followed steps in #27. Seemed to fix my issue. Not a real fix, but it worked for me.

neRok’s picture

Issue summary: View changes
Status: Postponed (maintainer needs more info) » Closed (fixed)

This issue is fixed as per #37 (git commit).

Re #40, #41, and #42, you need to use the latest beta (4), not an older dev.

joelrotelli’s picture

#19 and #25 works for me ! Thanks !!