Server Environment:
- apache2, php 5.2, ubuntu
- no apc or xcache, not even ob_gzhandler

Browsers:
exact same behaviour in FF/ubuntu, opera/ubuntu, epiphany/ubuntu

Situation:
Drupal's private file system with these 2 settings:
files are to be stored in ../privatefiles
temp files are to be stored in ../privatetemp

Node with imagefield.
Custom hook_nodeapi implementation that creates thumbnail of attached image and replaces originally uploaded file. This happens in the submit $op.

Problem:
after the node save, the thumbails gets created and put in the correct (private) folder. However, the image is not displayed in the browser on node view.
The path to the image is correct, and the image is really there.
Permissions and owernship of files and folders are ok.
No errors in apache error log. No .htaccess errors.
clearing my browser's cache has no effect

But, when I look at the node from another browser (opera), the image is shown correctly. When I log out and log back in with the original browser, the image is shown. When I go back to the node edit form after I just added the image, and click the back button on the form, the image is shown correctly.

Right after I upload the image, the watchdog has 2 errors:
- one saying:

Message fopen(../privatetemp/tmp_W5cxNb) [<a href='function.fopen'>function.fopen</a>]: failed to open stream: No such file or directory in /home/workspace/project/trunk/www/includes/file.inc on line 562.

It looks like the temp files are not written anywhere or erased too soon or...

Comments

jpoesen’s picture

jpoesen commented

Ok, I've almost found what's going on. After the above scenario, there's a session var left over from imagefield:

_SESSION['imagefield']['field_foo_image'][1] which is an array. One of its values is wrong:
_SESSION['imagefield']['field_foo_image'][1]['filepath'] is stil set to the temp file, which is long gone by now. It should contain the actual file path.

At the moment I don't know whether this is a timing issue with imageapi or whether the session var should not be there or...

I'll keep looking into it. If someone knows more about imagefield and its session vars...

update/workaround: In my case, my problem was 'solved' by adding:

  unset(_SESSION['imagefield']);

at the top of my foo.tpl.php, which is of course called after the node edit form has done its thing and the user is redirected to node view. I don't know why that session var is still there and whether it's useful. So far, no side effects...

@Dopry, any thoughts on this session var thing?

jpoesen’s picture

jpoesen commented

see also http://drupal.org/node/230848#comment-777261

dopry’s picture

dopry commented
Status: Active » Postponed (maintainer needs more info)

jpoesen: That temp path is appropriate.. It is used in a dynamic menu callback before the node is submitted and the file is saved, so we can use the url the file will live at before it is actually saved... After the node is submitted the file is saved it its final location, so requests for the image should no longer be redirected to drupal by apache... Mind you the file is saved to its destination before output is sent to the browser so there should be no chance of parallel requests causing a race condition.

unsetting it shouldn't hurt anything, however, I am really surprised that it fixes your issue. So your usual approach to development and support is changing things you don't understand and recommending it as a possible solution to other people?

dopry’s picture

dopry commented

Let me see if I grok this correctly...

You are using private files...
imageAPI and everything is creating the files it should be...

The file isn't being served by Drupal....

Have you read up on how private file handling works in drupal? I'm thinking there isn't a hook_file_download implemented that returns headers for your files.... You probably need to add a hook_file_download implementation to your module with the nodeapi thing to make it work with private files.

It sounds like it isn't a bug, you just didn't research how private file handling works in drupal.

jpoesen’s picture

jpoesen commented

I will look into hook_file_download. However, I didn't say the file isn't served at all. I said in my case, the file isn't served after it's been added though an imagefield upload, and processed in a hook_nodeapi, $op=submit.

After the above scenario, the image is not served. On logout/login or viewing with another browser, the image *is* served. Thus, though I'm obviously most likely wrong, I concluded that there's nothing wrong with the way I'm using private file handling.

I also didn't say my solution is a real solution, just a workaround that works for me atm and that may or may not indicate the session var has something to do with, which you have already disproved.

dopry’s picture

dopry commented

is this an imageAPI issue? ImageCache? ImageField? How do I setup a site step by step to reproduce your problem? I remember talking to you about it in CVS... it's a tweaky issue. The session may have something to do with it, but that session variable shouldn't be used in the normal serving of files...

jpoesen’s picture

jpoesen commented
Status: Postponed (maintainer needs more info) » Closed (fixed)

unable to reproduce