Just trying this module for the first time. Checked out from CVS today.

I have the default import path set in admin/settings/image_import as ftp/sphop

When I go to node/add/image_import the import path is pre-filled (by the module I assume) with ftp/sphop/
The trailing slash is not needed and causes an error, uploads fail as a result.

The obvious workaround is of course to delete the trailing slash...but it seems to be re-added and uploads still fail, watchdog says the following:
s_dir(): Stat failed for ftp/sphop//sphp_1999_12.jpg (errno=13 - Permission denied) in /home/perlucid/public_html/adrinux/includes/file.inc on line 508.

Quite infuriating :)

Comments

syscrusher’s picture

syscrusher commented
Assigned: Unassigned » syscrusher
Category: bug » support
Priority: Critical » Normal

Greetings!

I've just worked on a related issue (actually, almost identical symptoms) with another user. This error is probably not what it appears to be. There are two things you should check:

  1. Even if you're using the default configuration options, be sure to do a "Save Settings" at least once from the admin screen for image_import (q=admin/settings/image_import). The module relies on being able to read its settings from the system variables. (The new CVS version should alert you if you haven't saved the config yet -- look for a warning message to that effect.)
  2. Check the permissions on your import directory. This is about 90% likely to be the source of the problem. It turns out that the Drupal core upload.module reports the error you are seeing if it can't move the file from the import directory into Drupal's files directory due to permissions.

The second issue above is not, strictly speaking, a bug in image_import, but I agree with you that it is a major annoyance! I'm going to add logic in image_import's configuration check that specifically looks for upload directory permissions, and reports in a user-friendly way if there is a problem and what needs to be done to fix it. I can't (and shouldn't!) automatically tweak the permissions from inside the module, but I can (and will) report on where the problem is.

Please check the above, and let me know if this doesn't fix the problem. The other person who was having the same problem reported that this did fix it.

Kind regards,

Scott

syscrusher’s picture

syscrusher commented

Further info on this problem:

http://drupal.org/node/23179

adrinux’s picture

adrinux commented

OK, this does look like a duplicate of http://drupal.org/node/23179

I've not resolved it yet but will make further comments there, marking this issue as duplicate.