David Pratt wrote at 2005-8-17 18:08 -0300:
>Hi Dieter. Many thanks for your reply. The place in my workflow that it 
>failed was opening the image.
>IOError: cannot identify image file
> ...
>error here --> image = PIL.Image.open(original_file)

This does not look like a workflow problem.

Instead, PIL seems to be unable to determine the type of image
("jpg", "png", "gif", ...).
I cannot tell you why.

Looking at the traceback (where is the exception raised?)
and then at the corresponding code may give you a hint.

> ...
>I discovered that it does not appear possible to have a workflow act on 
>content immediately after being FTP'd to a site without generating the 
>'FTP 426 Error creating file' error.  If I FTP an image to the folder 
>as Manager with copy or move permission, it will trigger 426 Error 
>creating file and the following traceback.  The workflow will work for 
>regular operations within the portal, just not FTP.
>     *  Module OFS.CopySupport, line 92, in manage_cutObjects
>Copy Error: The action against the 
><em>A084.JPG</em> object could not be carried out. One of the following 
>constraints caused the problem:i
>  * The object does not support this operation
> -- OR --
>  * The currently logged-in user does not have the
>    <b>Copy or Move</b> permission respective to the object.

Xssss. Almost a Windows like message :-(

But, your traceback was definitely larger. Please post the whole one.

Probably, your workflow gets fired too early -- at a time
when the object is not yet put placed inside the Zope object hierarchy.
At such a time, Zope permission system does not yet work
(the permissions defined at objects in the hierarchy are passed down
to lower level -- however, they can only reach objects placed in the

The full traceback may tell us whether this hypothesis is true.

Zope maillist  -  Zope@zope.org
**   No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-dev )

Reply via email to