I've been getting this error message for a while whenever I tried to create an Image node using Image module. Now I finally sat down to investigate...
This is occurring on a Drupal 6.13 site (LAMP, PHP 5.2.6) with the current Image module and Private downloading (don't know whether that makes any difference).
Logging the calls to file_copy() in file.inc, where the error message is generated, I'm seeing the following: on a site that works, I get one call:
file_copy(files/images/temp/test.png, files/images/test.png, 0)
However, on the broken site I get two calls:
file_copy(files_private/images/temp/test.png, files_private/images/test.png, 0)
file_copy(files_private/images/test.png, files_private/images/test.png, 0)The first call returns success and I've confirmed that the copied file is there. However, in the second call, the file has disappeared! The statement
$source = realpath($source);
yields an empty string, leading to the
The selected file could not be copied, because no file by that name exists. Please check that you supplied the correct filename.
error message. (Note the empty %file variable.)
How did the copy get deleted???
A Google search turned up http://dominiquedecooman.com/blog/selected-file-could-not-be-copied-beca... which mentions the Workflow module as the culprit. I'm using Rules, not Workflow, but I found that disabling Rules made the error go away!
Actually, I'm not really using Rules yet, I had just installed it and tried working through Tutorial 2, but I got stuck, because Rules didn't behave as described (so I thought)...
I found the Tutorial 2 quite confusing, because I didn't have a clear mental image of 'rule sets', 'rules', and 'triggered rules' (and the differences between them) yet. The tutorial calls the rule set "Publish content", the rule "Publish action", the action "Publish content", and the triggered rule "Publishing rule". Add to that the built-in Node|"Publish content" action, and we have at least three different things called "Publish content"...
What happened was that in the step
- Select "Schedule Publish content" from the select box (it is listed in the Rules Scheduler group) and confirm the action by clicking "Next".
I erroneously selected 'Publish content' under 'Node', rather than "Schedule Publish content" under 'Rule Sets'.
This is clearly a user error on my part, but it has the very non-obvious and devastating effect of breaking Image uploads! Since
Dominique De Cooman had the exact same problem with the Workflow module, that probably makes at least two of us who fell into this trap.
Besides, there certainly are legitimate uses of the "Publish content" action when unpublished nodes are created, so this needs to be fixed in the Rules module.
While I was going up and down through Tutorial 2, I took the opportunity to make some changes:
- Number the bullets for easier reference.
- Add the {type} to the suggested names to help keeping track of what is what.
- Add the 'not published' condition (bug fix) in #22 and #23 to make the example behave as intended.
I hope this is an improvement...
Here's the result of my blunder:
array (
'rules' =>
array (
'rules_14' =>
array (
'#type' => 'rule',
'#set' => 'event_node_insert',
'#label' => 'Publishing rule {triggered rule}',
'#active' => 1,
'#weight' => '0',
'#categories' =>
array (
),
'#status' => 'custom',
'#conditions' =>
array (
),
'#actions' =>
array (
0 =>
array (
'#weight' => 0,
'#info' =>
array (
'label' => 'Publish created content',
'module' => 'Node',
'arguments' =>
array (
'node' =>
array (
'label' => 'Content',
'type' => 'node',
),
),
'base' => 'rules_core_action_execute',
'action_name' => 'node_publish_action',
'configurable' => false,
'label callback' => 'rules_core_node_label_callback',
'label_skeleton' => 'Publish @node',
),
'#name' => 'rules_core_node_publish_action',
'#settings' =>
array (
'auto_save' => 1,
'#argument map' =>
array (
'node' => 'node',
),
),
'#type' => 'action',
),
),
'#version' => 6003,
),
'rules_12' =>
array (
'#type' => 'rule',
'#set' => 'rules_publish_content',
'#label' => 'Publish action {rule}',
'#active' => 1,
'#weight' => '0',
'#categories' =>
array (
),
'#status' => 'custom',
'#conditions' =>
array (
),
'#actions' =>
array (
0 =>
array (
'#weight' => 0,
'#info' =>
array (
'label' => 'Publish Content',
'module' => 'Node',
'arguments' =>
array (
'node' =>
array (
'label' => 'Content',
'type' => 'node',
),
),
'base' => 'rules_core_action_execute',
'action_name' => 'node_publish_action',
'configurable' => false,
'label callback' => 'rules_core_node_label_callback',
'label_skeleton' => 'Publish @node',
),
'#name' => 'rules_core_node_publish_action',
'#settings' =>
array (
'auto_save' => 1,
'#argument map' =>
array (
'node' => 'content',
),
),
'#type' => 'action',
),
),
'#version' => 6003,
),
),
'rule_sets' =>
array (
'rules_publish_content' =>
array (
'arguments' =>
array (
'content' =>
array (
'label' => 'Content',
'type' => 'node',
),
),
'label' => 'Publish content {rule set}',
'status' => 'custom',
'categories' =>
array (
),
),
),
)
Comments
Comment #1
fagoThanks for that report and improving the tutorial. What may happen when you configure a rule is that the content is saved again, just after the node has been initially created. (Rules is just calling node_save() on nodeapi insert then.) What I assume is that the image module erroneously operates again on the second save (=update) of the node triggering this error.
Comment #2
joachim commentedHow is image module -- or any module for that matter -- meant to know that this is the second save?
If the second node_save() is being called from a nodeapi() insert op, then that does not seem to be good behaviour -- the first node_save has not finished at that point!
Comment #3
Hobbes-2 commentedSubscribe
Comment #4
ManyNancy commentedSometimes I run into this. Sometimes I don't. I was using 'after saving new content", and got this error. I changed to "content is going to be saved" and the error disappeared.
Is that pretty much what should be going on?
Thanks.
Comment #5
fago>How is image module -- or any module for that matter -- meant to know that this is the second save?
Fix the detection of when the code needs to run. E.g. when there is a flag in $node you react on it should be unset/changed that way that it won't do it again *if* the same node object is saved again.
>If the second node_save() is being called from a nodeapi() insert op, then that does not seem to be good behaviour -- the first node_save has not finished at that point!
That could be discussed but anyway it's the only way to save changes at this point. Still the bug would be triggered if node_save() would be just invoked again after the first node_save(), regardless how.