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.

Files: 

Comments

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.

Title:imagcache "permission denied" on local XAMPP (XP Home)imagcache "permission denied" fix
Component:Miscellaneous» Code
Category:support» bug

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);

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?

Not to hijack the thread, but...

why don't you get mac or use linux like the rest of the development world

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.

@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.

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.

Status:Active» Needs review

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_delete function 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.

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!

Hi,

Thanks a lot ron_s. This works perfect for me. Great support.

best regards,
Hauke

StatusFileSize
new1.32 KB

I made a modified version... can you test?

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.

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.

What are the permissions on the directory?

Internet Guest Account has read, write, execute, create, delete on the files directory and all subdirectories.

Does your webserver have write access to them?

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.

how were the directories created? Where they created by imagecache or copied in?

Created by imagecache.

are there any files remaining in the directory.

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.

Title:imagcache "permission denied" fix"permission denied" when deleting directories on Windows

better title.

This is not working for me as well.

Use the code in #8. It works.

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 ...

can anyone with a windows machine test that?

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.
¿?

Version:5.x-2.0» 5.x-2.1
StatusFileSize
new1.01 KB

Reroll the patches from #8 & #11
Please test.

Edit: #18 does not affect the patch, just a good practice.

This issue (removing empty folders) seems related to #311813: Warning on Flush of a Preset... only my 2Cents

Regards

Tried #311813 before, it does not fix the problem.

Just applied 259220-2.patch from #21 and it works like a charm!!

Thanks,
-- Jason

had 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

liquidcms, 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.

yup, 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.

StatusFileSize
new1.41 KB

The D5 backport of the code in in HEAD looks like:

<?php
/**
* Recursively delete all files and folders in the specified filepath, then
* delete the containing folder.
*
* Note that this only deletes visible files with write permission.
*
* @param string $path
*   A filepath relative to file_directory_path.
*/
function _imagecache_recursive_delete($path) {
  if (
is_file($path) || is_link($path)) {
   
unlink($path);
  }
  elseif (
is_dir($path)) {
   
$d = dir($path);
    while ((
$entry = $d->read()) !== false) {
      if (
$entry == '.' || $entry == '..') continue;
     
$entry_path = $path .'/'. $entry;
     
_imagecache_recursive_delete($entry_path);
    }
   
rmdir($path);
  }
  else {
   
watchdog('imagecache', t('Unknown file type(%path) stat: %stat ',
              array(
'%path' => $path'%stat' => print_r(stat($path),1))), WATCHDOG_ERROR);
  }
}
?>

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

What's the different from #11?
That code does not works.

Version:5.x-2.1» 6.x-2.x-dev
Status:Needs review» Needs work

ckng, 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.

Ok, we are talking about different thing.
Watchdog should be no problem, I'm referring to the recursive_delete that doesn't work.

ckng, 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.

We'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.

StatusFileSize
new1.18 KB

Reroll patch #21 to add in the watchdog to synced up.

Thanks ckng, this patch is working for my dev install.

edited: I am referring to 259220-3.patch

Status:Needs work» Fixed

committed my patch from #28 and thePanz's patch from #311813: Warning on Flush of a Preset.

Status:Fixed» Closed (fixed)

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

Can 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.

afaaro, 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.

I have done it but it isn't working seriously, If I try with other hosing it works

Anyone???

I'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.

Figured 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.)

Perfect 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!!