Karl Ramberg wrote:
Frank Shearar wrote:
-----Original Message----- From: Karl Ramberg [mailto:karl.ramberg@chello.se] Sent: 30 July 2004 11:53 To: Squeak Subject: [BUG][BFAV][m17n]Attachments download
Attachments downloaded with BAFV when m17n is installed
are corrupted.
Does this happen because of the encoding issues in the m17n
stuff reported by others? That Latin1/UTF-8 discussion of last week?
I'm not sure where and how it happens. Emails appear nicely in the email pane of BFAV. Files/ Attachments with the right filename are made and put in the right folder. But they are not gzip files. I don't understand the BFAV model and how it pulls down stuff from the server etc. so it's hard to be more specific. How are stuff stored on and downloaded from the BFAV server?
BFAV just stores the attachments as-is - when you download the post (say post 20254) it puts the attachment in (for example)
C:\Program Files\Squeak-3.2.2\email-file-repository\bfav.squeakfoundation.org\emails\20254-attachments
which contains
FixCorrectSelector-fbs.cs.gz
Do these files contain non-gzip data?
Maybe it's the decompression after it's downloaded from the BFAV server that do this.
I suspect unzipping of the attachment within the Squeak image corrupts the stream. I think you can verify this if you check the attachment on the file system. If that contains a corrupted attachement then I think we can say that BFAV corrupted the attachment. If BFAV saved the attachment on disk uncorrupted, but displays corrupted attachements in, say, a DecentReviewerNotePad, then I'd suspect the m17n stuff of corrupting the stream. That might well happen simply because BFAV doesn't set the right encoder - if I remember the m17n discussion correctly the default encoder uses UTF-8 but you can set it to something with a 1-1 mapping (like Latin1).
frank
******************************************************************* This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent RNID policy. If you are not the intended recipient you are advised that any use, dissemination, forwarding, printing or copying of this email is strictly prohibited. If you have received this email in error please notify the RNID Helpdesk by telephone on: +44 (0) 207 296 8282. The Royal National Institute for Deaf People Registered Office 19*23 Featherstone Street London EC1Y 8SL No. 454169 (England) Registered Charity No. 207720 ********************************************************************
Frank Shearar wrote:
Karl Ramberg wrote:
Frank Shearar wrote:
-----Original Message----- From: Karl Ramberg [mailto:karl.ramberg@chello.se] Sent: 30 July 2004 11:53 To: Squeak Subject: [BUG][BFAV][m17n]Attachments download
Attachments downloaded with BAFV when m17n is installed
are corrupted.
Does this happen because of the encoding issues in the m17n
stuff reported by others? That Latin1/UTF-8 discussion of last week?
I'm not sure where and how it happens. Emails appear nicely in the email pane of BFAV. Files/ Attachments with the right filename are made and put in the right folder. But they are not gzip files. I don't understand the BFAV model and how it pulls down stuff from the server etc. so it's hard to be more specific. How are stuff stored on and downloaded from the BFAV server?
BFAV just stores the attachments as-is - when you download the post (say post 20254) it puts the attachment in (for example)
C:\Program Files\Squeak-3.2.2\email-file-repository\bfav.squeakfoundation.org\emails\20254-attachments
which contains
FixCorrectSelector-fbs.cs.gz
This is where it get's corrupted. I can replace the gz file with a valid and it will open in a ChangeList browser or what ever I specify. I noticed MailUtility uses CrLfFileStream when it downloads files.
Do these files contain non-gzip data?
Not that I know.
Maybe it's the decompression after it's downloaded from the BFAV server that do this.
I suspect unzipping of the attachment within the Squeak image corrupts the stream. I think you can verify this if you check the attachment on the file system. If that contains a corrupted attachement then I think we can say that BFAV corrupted the attachment. If BFAV saved the attachment on disk uncorrupted, but displays corrupted attachements in, say, a DecentReviewerNotePad, then I'd suspect the m17n stuff of corrupting the stream. That might well happen simply because BFAV doesn't set the right encoder - if I remember the m17n discussion correctly the default encoder uses UTF-8 but you can set it to something with a 1-1 mapping (like Latin1).
BFAV saves the attachment corrupted.
Karl
I think one can add that the SWHTTPClient package could be the culpit of this bug.
Karl
Frank Shearar wrote:
Karl Ramberg wrote:
Frank Shearar wrote:
-----Original Message----- From: Karl Ramberg [mailto:karl.ramberg@chello.se] Sent: 30 July 2004 11:53 To: Squeak Subject: [BUG][BFAV][m17n]Attachments download
Attachments downloaded with BAFV when m17n is installed
are corrupted.
Does this happen because of the encoding issues in the m17n
stuff reported by others? That Latin1/UTF-8 discussion of last week?
I'm not sure where and how it happens. Emails appear nicely in the email pane of BFAV. Files/ Attachments with the right filename are made and put in the right folder. But they are not gzip files. I don't understand the BFAV model and how it pulls down stuff from the server etc. so it's hard to be more specific. How are stuff stored on and downloaded from the BFAV server?
BFAV just stores the attachments as-is - when you download the post (say post 20254) it puts the attachment in (for example)
C:\Program Files\Squeak-3.2.2\email-file-repository\bfav.squeakfoundation.org\emails\20254-attachments
which contains
FixCorrectSelector-fbs.cs.gz
Do these files contain non-gzip data?
Maybe it's the decompression after it's downloaded from the BFAV server that do this.
I suspect unzipping of the attachment within the Squeak image corrupts the stream. I think you can verify this if you check the attachment on the file system. If that contains a corrupted attachement then I think we can say that BFAV corrupted the attachment. If BFAV saved the attachment on disk uncorrupted, but displays corrupted attachements in, say, a DecentReviewerNotePad, then I'd suspect the m17n stuff of corrupting the stream. That might well happen simply because BFAV doesn't set the right encoder - if I remember the m17n discussion correctly the default encoder uses UTF-8 but you can set it to something with a 1-1 mapping (like Latin1).
frank
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent RNID policy. If you are not the intended recipient you are advised that any use, dissemination, forwarding, printing or copying of this email is strictly prohibited. If you have received this email in error please notify the RNID Helpdesk by telephone on: +44 (0) 207 296 8282. The Royal National Institute for Deaf People Registered Office 19*23 Featherstone Street London EC1Y 8SL No. 454169 (England) Registered Charity No. 207720
squeak-dev@lists.squeakfoundation.org
-
Frank Shearar -
Karl Ramberg