"stat failed" error (with "//" in file path) on files known to exist in the import directory

What's your setting for the import directory? Did you put a slash on the end of the directory? If so, try removing that. Please let me know, so I know whether to pursue this as a bug or not. I'm setting it as a "support request" in the meantime, until we verify your settings are correct.

Scott

Okay, thanks for checking. It's a bug now. :-) I'll try to get a patch out later tonight.

Scott

leofaoro wrote:
> Thanks so much for helping me (us) out. I installed the new version
> and the error persists. The difference is that it says which files
> "would be imported", as I have 2 test files in the dir.
>
> Here's the query results:
>
> image_import_default_import_path :12:"image_import";
> image_import_default_upload_path s:12:"image_import";
> image_import_force_delete s:1:"0";
> image_import_system_nou s:1:"0";
>
> The fill-in fields:
> - Image galleries: "i choose one"
> - title pattern: empty
> - import dir: image_import/
>
> So, here it is...let me know if I can help you in any other way. If
> you need admin access to my site I don't mind.

The info above is very helpful -- thanks. The fact that you see images that
"would be imported" and yet they don't import is a new and important clue. My
"preview" function uses almost all of the same execution paths as the actual
import, so any difference in behavior is narrowed down to just a few areas of
difference.

Since I can't seem to replicate this on my test environment, it would be very
helpful to take you up on your offer of Drupal admin access, if you don't mind.
Also, is it possible to get temporary shell or FTP access on the server? I would
not need root at all, just an account where I can execute "ls" and "cd" commands
within your Drupal file tree to see exactly how things are laid out and the
permission bits. If you can't do the shell access for me, please go to your
top-level Drupal directory and execute "ls -lR image_import" and send me the
results. I also need to know what login is running Apache on your server.

The reason I'm asking for this last bit is that it's possible the "//" is actually
a red herring and not the real source of the problem. Drupal's internal file
upload feature complains about not being able to open a file for a wide variety
of reasons. The file may be missing, or it may be locked down where Drupal can't
read or write it. Internally, what Drupal's upload.module does is to *move* the
file into Drupal's own files directory. My code, when "delete" is not enabled,
compensates for this by copying the file first and then moving the copy to
the original location. All of this works right only when the permissions are open
enough for each operation to happen. The upload.module code isn't very fine-grained
in its error messages, unfortunately, and reports the same error for a whole set
of different problems.

For what it's worth, your settings all appear to be correct and reasonable, so
I do think you've got an actual bug in my code rather than a config problem
at your end. I'll find it -- it just may take some digging. :-) Even if my code
isn't broken, and it's a permissions problem on the system, image_import.module
needs to get "smart" enough to pro-actively report the situation and tell you
what to do to fix it, instead of blindly proceeding and then letting upload.module
fail in mid-import. {sigh}

I'll look into this after work today. Thanks again for your patience and for
helping to refine this module.

Kind regards,

Scott

leofaoro reports that changing the permissions on his import temporary directory (in this case, $DOCUMENT_ROOT/image_import/) fixed the problem. The cause was that the web daemon user was not able to write to the directory.

This isn't something I can fix in image_module itself, but I can *test* for the problem and report it to the administrator, which I will do in the next release of the module.

For the record, the "//" in the path was in fact *not* a problem; this was just the error message being reported by upload.module in the absence of a more specific diagnostic.

Issue closed per email from leofaoro that the module now works correctly.

Scott

I'm experiencing the same problem, but I'm on a shared host with no shell access.
I'm used to this though, and use single use php scripts to create and chmod directories, that's allowed me to get image.module working amongst other things.

On my host Drupal will only upload files and images if files/ is owned by the apache user - just a question of having Drupal create the directory after modifying perms on the parent directory.
So I suspect Apache will also have to own the image_import/ directory - but if it does the ftp user I've set up can't access it to upload (even with perms set to 0777). Catch 22.
As far as I can see I can either set perms so that Drupal can move files from image_import/ , or set them so that image_import can be ftp'd into - but not both at the same time.

I'll think about this some more and talk with the hosting provider, but using this module may well require a move to a more flexible (and more expensive) web host.

I'm moving the status on this to "active" and "support request" since it's an ongoing issue but not actually a bug in the code per se.

From what I've experienced in testing, it's not essential that Apache own the image_import directory, only that this directory have permissions such that Apache can write to files placed therein. For most installations, it seems to work to set that particular directory to 777 permissions and let it still be owned by the FTP account.

{sigh} This is one of those really yucky issues with file permissions, where there just isn't really a good solution short of having full ACL support in the operating system *and* having all web hosting accounts get shell access so they can grant the ACL rights needed for Apache. And that, in turn, would require that the web hosting users know what ACLs are and how to use them. Alternatively, if all Apache hosting providers ran the daemon in "setuid" mode...but that's not going to happen any time soon, either, for a variety of good and poor reasons. As I said, no easy answers.

The best I can hope to do in the short term is just to report the problem to the admin, and make sure I document this issue carefully in the INSTALL.txt file for the module.

Sorry for the inconvenience. If anyone has suggestions for alternative plans, let me know.

Scott

Adding a clearer title in hopes that new users will spot this issue and be warned. :-)

not essential that Apache own the image_import directory, only that this directory have permissions such that Apache can write to files placed therein. For most installations, it seems to work to set that particular directory to 777 permissions and let it still be owned by the FTP account

This turned out to be true - I don't feel safe leaving it at 777 so other users can import their ftp uploads, but it'll do for me as the admin user to import them. Shared hosting forces compromises :)

I was also bitten by the admin uploads extensions bug reported in:
http://drupal.org/node/22417
http://drupal.org/node/20583

So it was double trouble, have noted that this is fixed in the most recent update though, so will get updated.
This module is coming along nicely, thanks for your work and help.

This may be a place where the %U or %u variables in the import path may be helpful. You can create subdirectories per user underneath the main import directory. Apache will need to be able to write in each of those user subdirectories, but they don't need to have any access to one another's directory or to the main one.

I know this is far from ideal, but as you say, it's a limitation of shared hosting until ACLs are widely used at the operating system level.

Scott