"permission denied" when deleting directories on Windows
| Project: | ImageCache |
| Version: | 5.x-2.0 |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | patch (code needs review) |
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.
#1
sorry 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.
#2
I 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);
#3
Thanks 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?
#4
Not 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.
#5
marked #263747: Windows directories give errors when flushed. as a duplicate
#6
@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.
#7
thanks 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.
#8
Technically 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_deletefunction as follows:function _imagecache_recursive_delete($dir) {$d = dir($dir);
if (is_dir($dir) && !is_link($dir)) {
if ($d = opendir($dir)) {
while (($entry = readdir($d)) !== false) {
if ($entry == '.' || $entry == '..') continue;
$path = $dir .'/'. $entry;
if (is_file($path)) unlink($path);
if (is_dir($path)) _imagecache_recursive_delete($path);
}
closedir($d);
}
return rmdir($dir);
}
return unlink($dir);
}
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.#9
Genius!
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!
#10
Hi,
Thanks a lot ron_s. This works perfect for me. Great support.
best regards,
Hauke
#11
I made a modified version... can you test?
#12
When flushing the preset, I receive the same error message with the patch:
* warning: rmdir(C:\xampp\htdocs\files\imagecache\user_image_thumb/pictures) [function.rmdir]: Permission denied in C:\xampp\htdocs\sites\all\modules\imagecache\imagecache.module on line 683.* warning: rmdir(C:\xampp\htdocs\files\imagecache\user_image_thumb) [function.rmdir]: Permission denied in C:\xampp\htdocs\sites\all\modules\imagecache\imagecache.module on line 683.
Line 683 is the
rmdir($path);line. The files are deleted from the directory, but the directory is not removed.#13
What 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.
#14
Internet Guest Account has read, write, execute, create, delete on the
filesdirectory and all subdirectories.I would think so, since I can manually delete any of the
imagecachesubdirectories, 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.
#15
better title.
#16
This is not working for me as well.
#17
Use the code in #8. It works.
#18
I 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
$entry_path = $path .'/'. $entry;with
$entry_path = $path .DIRECTORY_SEPARATOR. $entry;Should do the trick ...
#19
can anyone with a windows machine test that?
#20
I 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.
¿?