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.
Comments
Comment #1
zabelc CreditAttribution: zabelc commentedAfter 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:
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
Comment #2
bfroehle CreditAttribution: bfroehle commentedWhat 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 ?
Comment #3
zabelc CreditAttribution: zabelc commentedadmin/config/media/file-system
admin/reports/status/php
PHP Version 5.3.2-1ubuntu4.5
Comment #4
PanchoI 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.
Comment #5
zabelc CreditAttribution: zabelc commented@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".
Comment #6
a.siebel CreditAttribution: a.siebel commentedsubscribe... i have the same problem
Example:
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.
Comment #7
a.siebel CreditAttribution: a.siebel commentedUPDATE:
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?
EDIT:
Ähm... forgot to reload node_add page *g*.
Comment #8
metakel CreditAttribution: metakel commentedAfter 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:
After this in my second attempt the below AJAX error is shown:
(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.
Update
Revert to 7.x-1.0-alpha1 of this module fixed the problem.
Comment #9
montchr CreditAttribution: montchr commentedI'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.
Comment #10
metakel CreditAttribution: metakel commented@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?
Comment #11
h0tw1r3 CreditAttribution: h0tw1r3 commented** deleted irrelevant comment **
Comment #12
h0tw1r3 CreditAttribution: h0tw1r3 commentedWho wants to share what modules they are using? I'd be happy to take a look, but I can't reproduce.
Comment #13
montchr CreditAttribution: montchr commentedSorry for the delayed response. Here's all the modules I'm using (I doubt most are relevant but here you go):
@font-your-face
Admin
Administration Development tools
Autocomplete Deluxe
Multiselect
CTools (all enabled)
Context (all)
Calendar (all except Multiday)
Date (all)
Devel (all)
Font Reference
Hierarchical Select (all except 'Menu')
Imagecache Actions (+ Canvas Actions)
Pathologic
HTML5 Tools
File Entity
IMCE (+ Mkdir)
jPlayer
Media (+ Internet Sources + YouTube)
Video (+ UI + JS)
AddThis
Backup and Migrate
Better Formats
Comment Notify
Custom Breadcrumbs
Diff
Elements
Entity API
Entity tokens
Global Redirect
Image resize filter
Insert
Libraries
Menu attributes
Menu Block (+ Export)
Pathauto
Quick Tabs (+ Styles)
Search 404
Secure Pages
Shadowbox
Site map
Token
Transliteration
Page Title
Taxonomy Manager
Delta API (+ 'Blocks' + 'Color' + UI)
Omega Tools
External Links
IMCE Wysiwyg API bridge
Superfish
Wysiwyg
Views (+ UI)
Views Bulk Operations
Views Galleriffic
Views Infinite Scroll
Views Slideshow (+ Cycle)
Hope that helps...
Comment #14
metakel CreditAttribution: metakel commentedI have too many modules!
Comment #15
montchr CreditAttribution: montchr commented@h0tw1r3: Any insights?
Comment #16
h0tw1r3 CreditAttribution: h0tw1r3 commented@montchr: thanks for the modules list. I'm looking into it in more detail. Will respond back in a few days with a update.
Comment #17
caspervoogt CreditAttribution: caspervoogt commentedAlso 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!
Comment #18
caspervoogt CreditAttribution: caspervoogt commentedMy 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.
Comment #19
metakel CreditAttribution: metakel commentedI'd tried to chmod 700 the "public:" directory but I still got:
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.
Comment #20
Petr IllekI'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...
Comment #21
montchr CreditAttribution: montchr commentedI 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.
Comment #22
silkogelman CreditAttribution: silkogelman commentedI 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.
Comment #23
marcoka CreditAttribution: marcoka commentedexactly the same as mentioned #22
Comment #24
silkogelman CreditAttribution: silkogelman commentedand to confirm:
there was an erroneous public: directory created in the Drupal installation.
Comment #25
govind.maloo CreditAttribution: govind.maloo commentedThis 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.
Comment #26
h0tw1r3 CreditAttribution: h0tw1r3 commentedSorry 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.
Comment #27
silkogelman CreditAttribution: silkogelman commentedI 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
Comment #28
marcoka CreditAttribution: marcoka commentedthat 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.
Comment #29
Deciphered CreditAttribution: Deciphered commentedCan 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.
Cheers,
Deciphered.
Comment #30
metakel CreditAttribution: metakel commentedIt still appears on the last dev, and even on the latest Drupal 7.9.
Comment #31
Deciphered CreditAttribution: Deciphered commentedThanks metakel,
I'll try to reproduce this evening.
Cheers,
Deciphered.
Comment #32
Deciphered CreditAttribution: Deciphered commentedFollowed 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.
Cheers,
Deciphered.
Comment #33
pmichelazzoHi 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.
Comment #34
spaghetti_code CreditAttribution: spaghetti_code commentedSalam 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.
Edit:
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.
Edit2:
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.
Comment #35
pacproduct CreditAttribution: pacproduct commentedHi,
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:
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:
Could someone confirm that solves the problem for them too?
Comment #36
Deciphered CreditAttribution: Deciphered commentedThanks pacproduct, I appreciate your research, it looks like I should be able to confirm and resolve the issue shortly.
Comment #37
Deciphered CreditAttribution: Deciphered commentedI 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.
Comment #38
spaghetti_code CreditAttribution: spaghetti_code commentedpacproduct solution worked for me (also the missing $ is already reported and fixed), thx gentlemen.
Comment #40
czigor CreditAttribution: czigor commentedI 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).
Comment #41
aliaric CreditAttribution: aliaric commentedYes, i met same problem with my custom module. I one situation it works fine. In another - problem appears...
Subscribe.
Comment #42
mncrff CreditAttribution: mncrff commentedI 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.
Comment #43
neRok CreditAttribution: neRok commentedThis 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.
Comment #44
joelrotelli CreditAttribution: joelrotelli commented#19 and #25 works for me ! Thanks !!