On each run of cron or when uploading an image I get warnings like this one:
realpath() [function.realpath]: Unable to access /home/html/DOMAIN/public_html/images/temp in file /home/html/jazda-na-f1.sk/public_html/includes/file.inc on line 182.

The reason seems to be that the cron hook (image.module, line 136) and _image_filename function (line 828) pass to file_create_path the content of the variable image_default_path, which is supposed to be a subdirectory of the files directory. Function file_create_path tries first to check whether the path is contained either within the files directory or within the temporary directory, only at the end it tries to prefix the path with the files directory location.

The path passed to file_create_path should be prefixed in both occurences with the files directory location to avoid unnecessary lookups and warnings for example like in _image_check_settings():

  $image_path = file_create_path(file_directory_path() .'/'. variable_get('image_default_path', 'images'));
  $temp_path = rtrim($image_path, '/') .'/temp';

Comments

hitka’s picture

Status: Active » Needs review

Not attaching a patch, solution offered in the issue body (I hope that's enough).

Hetta’s picture

Status: Needs review » Needs work

Nope, I can't test your solution, cos I keep getting errors with what you've suggested. Please roll a patch.

hitka’s picture

StatusFileSize
new921 bytes

Attaching a patch against image module release "Image 6.x-1.x-dev (2008-Mar-03)". Nothing fancy, just prefix the image default path with file_directory_path() .'/'. before passing to file_create_path.

hitka’s picture

Priority: Minor » Normal
Status: Needs work » Needs review

Forgot to update the status.

BTW in the issue 209090 the problem actually the same, but unfortunately not all occurrences of variable_get('image_default_path', 'images') passed to file_create_path were fixed to be prefixed with file_directory_path() .'/'.

sun’s picture

This looks very very valid.

corbacho’s picture

Same problem here with Image 6.x-1.0-alpha4

I don't have this problem in local installation with Windows XAMPP but when I put it on the server starts Linux to appear this errors. Why? Anyway, I have tested a fresh installation on the server. Details:

Drupal 6.9 installed in root of domain with only Image module.
Default directory in file system: sites/default/files
Installed only the module images, with the default directory "images"

By the way, I create the folder "temp" via FTP manually to avoid some problems of SAFE MODE with the installation of the module.

When I create an attachment of a file of a image (by drupal core), nothing happens.
When I create an node image, I upload a photo and that is done correctly but a lot of warnings "unable to access" appears, like the title of this issue says "unnecesary".

8 messages like these ones:

# warning: realpath() [function.realpath]: Unable to access /srv/<manually erased :). Root directory>/images/temp/typewriter_128_0.thumbnail.png in /srv/<manually erased :). Root directory>/includes/file.inc on line 182.
# warning: realpath() [function.realpath]: Unable to access /srv/<manually erased :). Root directory>/images/temp in /srv/<manually erased :). Root directory>/includes/file.inc on line 188.
corbacho’s picture

Hi again,

I have the same problem also in uploading user pictures (in their profiles). It works, but it displays that "unnecesary" warnings.
I don't know how to create a patch, but change this line

$destination = variable_get('user_picture_path', 'pictures') .'/picture-'. $form['#uid'] .'.'. $info['extension'];
by this one

$destination = file_directory_path() .'/'. variable_get('user_picture_path', 'pictures') .'/picture-'. $form['#uid'] .'.'. $info['extension'];

in the file user.module

That should work.

I don't know then if this issue is due of Image module or has to do with this other issue http://drupal.org/node/155781 ?

sun’s picture

StatusFileSize
new3.51 KB
sun’s picture

Status: Needs review » Fixed

Committed to 6.x and 5.x-2.x.

Status: Fixed » Closed (fixed)

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