Hi there,
I have installed imagecache and the corresponding ImageCache API module and activated both of them. Unfortunatly I always get some error Messages about "permission denied", on my local testing environment. For example I receive the following error message after creating a new preset:
warning: rmdir(C:\xampp\htdocs\meine_seite\files\imagecache\avatar_thumb/avatar_pictures) [function.rmdir]: Permission denied in C:\xampp\htdocs\meine_seite\sites\all\modules\imagecache\imagecache.module on line 680.
Another error message is beeing displayed within the log book:
Imagecache - Failed generating an image from files/avatar_pictures/picture-1.jpg using imagecache preset .
While Imagecache is creating the optimised version of a picture, it is creating the new subfolders within the "files" directory. That far it works. However there seems to be a permission problem when writing into those folders.
On my hosted webspace, where I can define the permisions explicitly via chmod, it works fine. But I would like to make it work on my local dev envrionment (Win XP Home | XAMPP). I checked the properties of the affected directories and found out that it's read only. I can actually uncheck the checkbox and apply the changes for al subfolders, but when opening the properties again, the box is still checked as "protected". I assume that my problem is related to this behavior.
I hope someone can help here.
thanks and regards,
H.
Comment | File | Size | Author |
---|---|---|---|
#34 | 259220-3.patch | 1.18 KB | ckng |
#28 | imagecache_259220.patch | 1.41 KB | drewish |
#21 | 259220-2.patch | 1.01 KB | ckng |
#11 | 259220.patch | 1.32 KB | dopry |
Comments
Comment #1
dopry CreditAttribution: dopry commentedsorry don't have a windows machine... why don't you get mac or use linux like the rest of the development world. That said if you figure out the perms issue doc it please. I certainly won't be working on windows perms as I simply don't care about the OS.
Comment #2
PixelClever CreditAttribution: PixelClever commentedI don't know if this is really a fix or if I took away some important functionality, however when I went to line 680 of the imagecache.module file, then looked for the equivalent line in the earlier version I noticed this one difference: in the earlier version the rmdir has an @ in front of it. I changed the code on line 680 of version 2 to match and the error messages went away. So this is what I have on line 680 now and it works: @rmdir($path);
Comment #3
jfall CreditAttribution: jfall commentedThanks Aaron!
Your simple suggestions fixed the issue for me too - I owe you a beer.
Unfortunately I have never seen this syntax before...
dopry - does this fix make sense? Would you be willing to patch that back into the next release?
Comment #4
jfall CreditAttribution: jfall commentedNot to hijack the thread, but...
With enough Win-frustration hours to start a whole new career, I get where you're coming from here. But the unfortunate fact is that we don't all have such a simple choice. At our community College, I am part of a vocal and persistent group of faculty who are trying to get off the M$ bandwagon. We've made some in-roads, but for a variety of reasons we never make any headway against the OS. To adopt a non-Win OS means no support, no infrastructure, no software licenses, restricted interface to the wider college computing environment. There really is not much choice - we develop on WAMP.
I'm not saying at all that you should feel compelled to test for Win or care about it at all - just that it's not always a personal decision to use it. But even those of us with a dirty little WAMP secret in the closet still want the software to work - and we're willing to help were we can.
Comment #5
drewish CreditAttribution: drewish commentedmarked #263747: Windows directories give errors when flushed. as a duplicate
Comment #6
dopry CreditAttribution: dopry commented@jfall: yeah sorry about your situation, but I write tools and distribute them for free and I'm not going to use tools I have to pay for to write tools I distribute for free. :)
I understand the '@' error suppression in PHP, but it is just that, error suppression. It hides a symptom and isn't a solution. Plus it's also a very expensive operator in terms of performance and memory. We need to figure out why rmdir fails, possibly even do an if (is_dir($path) && rmdir($path)) or something similar.
I don't think just hiding the error message is a good idea.
.darrel.
Comment #7
jfall CreditAttribution: jfall commentedthanks for the clues - if I get some time (and a better PHP dev env ;-) I'll look into this and see if I can suggest a more suitable solution. At least for the time being, the error suppression hack does allow me to use the module on my dev. machine - fortunately we hire-out hosting, so the prod site rides on LAMP.
thanks man.
Comment #8
ron_s CreditAttribution: ron_s commentedTechnically not an "official" patch, but I think I might have a solution for this. In the PHP manual for
rmdir
, a developer has offered a recommended approach for removing directories. I took this recommendation and modified the_imagecache_recursive_delete
function as follows:Not only does this get rid of the error message, but it also successfully removes the subdirectories out of
imagecache
. Give it a try and let me know if it works for you.Comment #9
jfall CreditAttribution: jfall commentedGenius!
ron_s - hero of this thread!
I tested a bunch of cases. The only thing I noticed is that removing a preset does not delete the directory structure for that preset. But a flush does. Perhaps that's nothing to do with your patch, just way imagecache works? - I haven't looked into it.
But the proposed patch certainly eliminates the error reported here, running on WAMP. I'm not ready to move 2.0 to my production server, so I can't test this on LAMP - perhaps someone else can and report that this doesn't break anything?
I suspect once we get a little more testing, dopry will want this rolled as a proper patch before considering it for a commit?
thanks ron!
Comment #10
hawkster CreditAttribution: hawkster commentedHi,
Thanks a lot ron_s. This works perfect for me. Great support.
best regards,
Hauke
Comment #11
dopry CreditAttribution: dopry commentedI made a modified version... can you test?
Comment #12
ron_s CreditAttribution: ron_s commentedWhen flushing the preset, I receive the same error message with the patch:
Line 683 is the
rmdir($path);
line. The files are deleted from the directory, but the directory is not removed.Comment #13
dopry CreditAttribution: dopry commentedWhat are the permissions on the directory? Does your webserver have write access to them? how were the directories created? Where they created by imagecache or copied in? are there any files remaining in the directory.
Comment #14
ron_s CreditAttribution: ron_s commentedInternet Guest Account has read, write, execute, create, delete on the
files
directory and all subdirectories.I would think so, since I can manually delete any of the
imagecache
subdirectories, and the next time I visit a web page imagecache recreates the subdirectory and any necessary files.Created by imagecache.
No, directory is empty. Patch is just tripping up on the final step of removing the directory. I know it might not be accurate, but the code in post #8 works.
Comment #15
drewish CreditAttribution: drewish commentedbetter title.
Comment #16
sparkguitar05 CreditAttribution: sparkguitar05 commentedThis is not working for me as well.
Comment #17
ron_s CreditAttribution: ron_s commentedUse the code in #8. It works.
Comment #18
mdixoncm CreditAttribution: mdixoncm commentedI think the issue is caused by the use of the Unix '/' as the directory separator (rather than the windows '\') on line 680 - replacing the line
with
Should do the trick ...
Comment #19
drewish CreditAttribution: drewish commentedcan anyone with a windows machine test that?
Comment #20
rhrueda CreditAttribution: rhrueda commentedI also have these warnings
# warning: imagecreatetruecolor() [function.imagecreatetruecolor]: Invalid image dimensions in D:\...\sites\all\modules\imageapi\imageapi_gd.module on line 129.
# warning: imagecopyresampled(): supplied argument is not a valid Image resource in D:\...\sites\all\modules\imageapi\imageapi_gd.module on line 62.
¿?
Comment #21
ckngReroll the patches from #8 & #11
Please test.
Edit: #18 does not affect the patch, just a good practice.
Comment #22
thePanz CreditAttribution: thePanz commentedThis issue (removing empty folders) seems related to #311813: Warning on Flush of a Preset... only my 2Cents
Regards
Comment #23
ckngTried #311813 before, it does not fix the problem.
Comment #24
jsm174 CreditAttribution: jsm174 commentedJust applied 259220-2.patch from #21 and it works like a charm!!
Thanks,
-- Jason
Comment #25
liquidcms CreditAttribution: liquidcms commentedhad similar issue with editing presets and flushing.. patch in #21 fixes both. thanks
btw.. does anybody actually do devel in linux?? even a mac is pretty painful for devel..pretty though.. i have a mac mini for my entertainment system - it rocks.. but devel.. osx is yrs behind winxp.. lol
Comment #26
drewish CreditAttribution: drewish commentedliquidcms, sounds like you haven't been to a drupalcon. windows is alwasy the minority. you're much more likely to see someone using osx or linux. imho osx has the best of all worlds, unix under the hood and a pretty UI.
Comment #27
liquidcms CreditAttribution: liquidcms commentedyup, i was in Boston, saw a few MAC laptops, still figured those were graphics designer types.. lol not people actually writing code.
I've used Linux in various flavors for over 20 yrs, osx for only a few months with my mini entertainment center.. and the "pretty gui" drives me nuts.. very inconsistent - some places delete key deletes things, some places it doesn't, need to do key commands with mouse to do almost anyting you can easily just right click in xp, lots of little things that just seem to be inconsistent or counter-intuitive.. but it is pretty.. lol
plus things still hang all the time and i need to go in and kill the process - but i guess you can write bad apps for any os.
Comment #28
drewish CreditAttribution: drewish commentedThe D5 backport of the code in in HEAD looks like:
Anyone want to try running that? I'd prefer to keep the code synced up as much as possible.
update: decided to not be lazy and added a patch
Comment #29
ckngWhat's the different from #11?
That code does not works.
Comment #30
drewish CreditAttribution: drewish commentedckng, it uses the correct d5 watchdog parameters. if it doesn't work in D5 then it doesn't D6 which is exactly why i want to keep the code synched up.
Comment #31
ckngOk, we are talking about different thing.
Watchdog should be no problem, I'm referring to the recursive_delete that doesn't work.
Comment #32
drewish CreditAttribution: drewish commentedckng, you'd asked what was different from #11, i explained the differences. and if you're reporting that the patch in #28 doesn't work then the code in HEAD doesn't work either, hence the version bump. we need to make sure this gets fixed everywhere.
Comment #33
ckngWe're having communication breakdown =)
Yes, recursive_delete in patch #28 does not work, the watchdog is fine.
You might want to check out the recursive_delete patch in #21 which work, you can add in the watchdog portion.
Comment #34
ckngReroll patch #21 to add in the watchdog to synced up.
Comment #35
rtandon CreditAttribution: rtandon commentedThanks ckng, this patch is working for my dev install.
edited: I am referring to 259220-3.patch
Comment #36
drewish CreditAttribution: drewish commentedcommitted my patch from #28 and thePanz's patch from #311813: Warning on Flush of a Preset.
Comment #37
Anonymous (not verified) CreditAttribution: Anonymous commentedAutomatically closed -- issue fixed for two weeks with no activity.
Comment #38
afaaro CreditAttribution: afaaro commentedCan you anyone direct me how to do this because am tired of this error and not working the imagecache
* warning: rmdir(/home/***/public_html/sites/default/files/imagecache/thumb) [function.rmdir]: Permission denied in /home/***/public_html/sites/all/modules/imagecache/imagecache.module on line 743.
* warning: rmdir(/home/***/public_html/sites/default/files/imagecache/thumb) [function.rmdir]: Permission denied in /home/***/public_html/sites/all/modules/imagecache/imagecache.module on line 743.
Comment #39
ckngafaaro, this has long been fixed.
Check your owner/permission to sites/default/files/imagecache/thumb, does your webserver process owner has access to the folder.
Comment #40
afaaro CreditAttribution: afaaro commentedI have done it but it isn't working seriously, If I try with other hosing it works
Comment #41
afaaro CreditAttribution: afaaro commentedAnyone???
Comment #42
dambrisco CreditAttribution: dambrisco commentedI've been having the same issue as afaaro. My modules and core are both updated properly, and Internet Guest Account has Write, Read, and Execute. I'm on Windows XP. Of course, the error I've been getting reads as a failure with the "unlink" function, which, although I'm unfamiliar with that precise term, should function as rmdir as far as I can tell.
Comment #43
dambrisco CreditAttribution: dambrisco commentedFigured out what I was doing wrong:
When you place a module in your modules directory, make sure you apply permissions to all sub-folders and files, as well.
If you're in doubt, just navigate to your modules folder, get to the security tab, go into Advanced, check the "Replace permission entires..." option, and hit ok, then confirm.
(I know it's seems obvious, but when you're a beginner even the simple things can trip you up, obviously.)
Comment #44
javilete CreditAttribution: javilete commentedPerfect ron_2, that function worked for me perfectly removind a directory and all its content. I also had a recursive function quite similar but I always got the same error "denied permision: rmdir(....)".
Thanks a lot!!