Hey Derick and all...
I just thought I would follow up on this again and see if anyone can
shed any light on this. It just happened again and I'm stumped as to
how to prevent the script from dying when it tries to parse an email
that has an image path that is incorrect in the header. As mentioned,
this is the Warning i'm receiving (below)... any help is REALLY
appreciated!
Will just ignoring all warnings allow this to right right? not the
right solution, but its something? Don't think it will help though.
Error below.... Thanks again
<br />
<b>Warning</b>: fopen(/tmp/13420-1/cam_data/photo093.jpg) [<a
href='function.fopen'>function.fopen</a>]: failed to open stream: No
such file or directory in <b>/usr/include/php/ezcomponents-2007.1.1/
Mail/src/parser/parts/file_parser.php</b> on line <b>131</b><br />
<br />
<b>Warning</b>: stream_filter_append() expects parameter 1 to be
resource, boolean given in <b>/usr/include/php/ezcomponents-2007.1.1/
Mail/src/parser/parts/file_parser.php</b> on line <b>173</b><br />
<br />
<b>Fatal error</b>: Uncaught exception 'ezcBaseFileNotFoundException'
with message 'The file '/tmp/13420-1/cam_data/photo093.jpg' could not
be found.' in /usr/include/php/ezcomponents-2007.1.1/Mail/src/parts/
fileparts/disk_file.php:86
Stack trace:
#0 /usr/include/php/ezcomponents-2007.1.1/Mail/src/parts/file.php(93):
ezcMailFile->__set('fileName', '/tmp/13420-1/ca...')
#1 /usr/include/php/ezcomponents-2007.1.1/Mail/src/parts/fileparts/
disk_file.php(32): ezcMailFilePart->__construct('/tmp/13420-1/ca...')
#2 /usr/include/php/ezcomponents-2007.1.1/Mail/src/parser/parts/
file_parser.php(246): ezcMailFile->__construct('/tmp/13420-1/ca...')
#3 /usr/include/php/ezcomponents-2007.1.1/Mail/src/parser/parts/
multipart_parser.php(146): ezcMailFileParser->finish()
#4 /usr/include/php/ezcomponents-2007.1.1/Mail/src/parser/parts/
multipart_parser.php(180): ezcMailMultipartParser->parseBody('------
=_Part_84...')
#5 /usr/include/php/ezcomponents-2007.1.1/Mail/src/parser/parts/
rfc822_parser.php(111): ezcMailMultipartParser->parseBody('------
=_Part_ in <b>/usr/include/php/ezcomponents-2007.1.1/Mail/src/parts/
fileparts/disk_file.php</b> on line <b>86</b><br />
On Dec 29, 2007, at 5:06 PM, Dave F wrote:
> Hey Derick,
>
> So, I checked out the message source, and what you suggested as a
> possible cause was exactly that. Looking at the headers, I see the
> following
>
> Content-Disposition: attachment; filename="cam_data/photo067.jpg"
>
> I understand what's causing it, but have no idea how to prevent it
> from happening again. What's weird is that the file attachment is
> "cam_data_photo067.jpg" yet I see no reference of that file in the
> email. there is a long string that appears to be the encoded data
> for the attachement. but I'm not sure.
>
> Here is part of the source below
>
> Any help is really appreciated! Thanks again.
>
> Fish
> ><>
>
> ------=_Part_1137874_19221738.1198904463082
> Content-Type: text/html; charset=iso-8859-1
> Content-Transfer-Encoding: 7bit
>
> <html>
> <body marginwidth="0" marginheight="0" leftmargin="0" topmargin="0"
> bgcolor="#FFFFFF">
> <table border="0" width="640" cellspacing="0" cellpadding="0"><tr><td>
> <img src="cid:cam_data/photo067" alt="cam_data/photo067.jpg"><br><br>
> </td></tr></table>
> </body></html>
>
> ------=_Part_289666_4677360.1198904468226
> Content-Type: image/jpeg; name="cam_data/photo067.jpg"
> Content-Transfer-Encoding: base64
> Content-ID: <cam_data/photo067>
> Content-Disposition: attachment; filename="cam_data/photo067.jpg"
> /9j/4AAQSkZJRgABAgEAkACQAAD/
> 2wCEAAwICQoJBwwKCQoNDAwOER0TERAQESQZGxUdKiUsLCkl
> KSgvNEM5LzE/
> MigpOk87P0VHS0xLLThSWFFJV0NJS0gBDA0NEQ8RIhMTIkgwKTBISEhISEhISEhI
> SEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISP/
> AABEIAPABQAMBIQACEQED
> EQH/3QAEABT/
> xAGiAAABBQEBAQEBAQAAAAAAAAAAAQIDBAUGBwgJCgsQAAIBAwMCBAMFBQQEAAAB
> fQECAwAEEQUSITFBBhNRYQcicRQygZGhCCNCscEVUtHwJDNicoIJChYXGBkaJSYnKCkqNDU2Nzg5
> OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqio6Slpqeo
> qaqys7S1tre4ubrCw8TFxsfIycrS09TV1tfY2drh4uPk5ebn6Onq8fLz9PX29/
> j5+gEAAwEBAQEB
> AQEBAQAAAAAAAAECAwQFBgcICQoLEQACAQIEBAMEBwUEBAABAncAAQIDEQQFITEGEkFRB2FxEyIy
> gQgUQpGhscEJIzNS8BVictEKFiQ04SXxFxgZGiYnKCkqNTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNk
> ZWZnaG... (and this goes on and on)
>
>
> On Dec 29, 2007, at 1:44 PM, Dave Fischetti wrote:
>
>> Hey Derick, thanks for the quick reply. I didnt mean to assume that
>> it was an EZ error, I guess I was inquiring more for guidance,
>> which is appreciated.
>>
>> I figured the folder was deleted afterwards, even though I got the
>> PHP warning multiple times for the same email. It seems the email
>> was still in the queue but the file attached was deleted.
>>
>> I am mobile right now, but will check the headers and get back to
>> you a little later today.
>>
>> Thanks again!
>>
>> Dave
>>
>> Sent from my iPhone
>>
>> On Dec 29, 2007, at 1:04 PM, Derick Rethans <[EMAIL PROTECTED]> wrote:
>>
>>> Hello Dave,
>>>
>>> On Sat, 29 Dec 2007, Dave Fischetti wrote:
>>>
>>>> Hey all, my EZ mail parser has be running GREAT for weeks since I
>>>> launched it. Last night I had a VERY weird error occur. I had an
>>>> email
>>>> come in from a user with an image attachement. The file name was
>>>> that
>>>> appeared in the email was:
>>>>
>>>> "cam_data_photo067.jpg"
>>>>
>>>> but for some reason It hung the script when it was trying to parse.
>>>> The error I receive is something along the lines of:
>>>
>>> [snip error]
>>>
>>>> As you can see, it for some reason put a "/" in place of "_" so it
>>>> things that "cam_data" is a folder. Or so it appears. When I went
>>>> and
>>>> looked in /tmp the folder "12174-1" was not there.
>>>
>>> I don't think we replace / with _ - that would be weird to do, so
>>> perhaps somewhere in the headers there is a cam_data/photo067.jpg
>>> string. If you can provide the raw mail, we can check that.
>>>
>>>> I couldnt figure out a way to stop this error so I simply created
>>>> the
>>>> "12174-1" and "cam_data" folders and put an image called
>>>> 'photo067.jpg' in there. That allowed it to get past that error and
>>>> parse the rest of the emails.
>>>>
>>>> if ANYONE has any idea why this happened, I'd really appreciate
>>>> some
>>>> help. I'm kinda lost and would like to prevent it from happening
>>>> again.
>>>
>>> The 12174-1 directory will be removed at the end of the request,
>>> just
>>> like all attached files. The documentation describes that in the
>>> following class documentation:
>>> http://ezcomponents.org/s/ezcMailParser
>>>
>>> regards,
>>> --
>>> Derick Rethans
>>> eZ components Product Manager
>>> eZ systems | http://ez.no
>
--
Components mailing list
[email protected]
http://lists.ez.no/mailman/listinfo/components
