From: Ron G. <ro...@fo...> - 2006-06-09 02:54:55
|
I am using 2.0.10 with Postgres 8.0 backend. We have found that a great many of the attachments received are showing up as 0 bytes and have basically disappeared. Since there is no way of retrieving these files, it is of some concern. Generally, it is prevalent in pdf or in one support request all .hmd (our proprietary format) files. When I look at the database table (mm_attachment) the record has a body field of '' Some files are also being stored with the incorrect content_type e.g. 40103;"2140";"6950";"lines 6009.hmd";"application/octet-stream";"TRUE";"''";"FALSE" 40104;"2141";"6950";"lines 6009.msd";"application/octet-stream";"TRUE <--- 40109;"2144";"6951";"lines 6009.hmd";"application/octet-stream";"TRUE";"''";"FALSE" 40108;"2143";"6951";"lines 6009.msd";"unknown/unknown";"TRUE" <--- 40109;"2144";"6951";"lines 6009.hmd";"application/octet-stream";"TRUE";"''";"FALSE" I would appreciate advice on the attachment problem or a way of storing them to safeguard their loss. Ron Goodwin |
From: Vishal K. <vis...@gm...> - 2006-06-09 09:02:04
|
Even I have experienced this problem in 2.0.8. esp the text or *.eml attachment are missing sometimes On 6/9/06, Ron Goodwin <ro...@fo...> wrote: > > I am using 2.0.10 with Postgres 8.0 backend. We have found that a great > many of the attachments received are showing up as 0 bytes and have > basically disappeared. Since there is no way of retrieving these files, i= t > is of some concern. Generally, it is prevalent in pdf or in one support > request all .hmd (our proprietary format) files. > > > > When I look at the database table (mm_attachment) the record has a body > field of '' > > > > Some files are also being stored with the incorrect content_type e.g. > > > > 40103;"2140";"6950";"lines 6009.hmd > ";"application/octet-stream";"TRUE";"''";"FALSE" > > 40104;"2141";"6950";"lines 6009.msd";"application/octet-stream";"TRUE > =DF- > > 40109;"2144";"6951";"lines 6009.hmd > ";"application/octet-stream";"TRUE";"''";"FALSE" > > 40108;"2143";"6951";"lines 6009.msd";"unknown/unknown";"TRUE" > =DF- > > 40109;"2144";"6951";"lines 6009.hmd > ";"application/octet-stream";"TRUE";"''";"FALSE" > > > > I would appreciate advice on the attachment problem or a way of storing > them to safeguard their loss. > > > > Ron Goodwin > > > > _______________________________________________ > Mailmanager-users mailing list > Mai...@li... > https://lists.sourceforge.net/lists/listinfo/mailmanager-users > > > --=20 With Best Regards, Vishal Kashyap. http://www.vishal.net.in |
From: Kevin C. <ke...@lo...> - 2006-06-09 09:49:56
|
On Fri, Jun 09, 2006 at 10:56:21AM +0800, Ron Goodwin wrote: > > I am using 2.0.10 with Postgres 8.0 backend. We have found that a great many > of the attachments received are showing up as 0 bytes and have basically > disappeared. Since there is no way of retrieving these files, it is of some > concern. Generally, it is prevalent in pdf or in one support request all > .hmd (our proprietary format) files. > > When I look at the database table (mm_attachment) the record has a body > field of '' Ron, What encoding is your database currently set to? Connecting to the database using the psql command line client should show this when you do \l+ > Some files are also being stored with the incorrect content_type e.g. > > 40103;"2140";"6950";"lines > 6009.hmd";"application/octet-stream";"TRUE";"''";"FALSE" > > 40104;"2141";"6950";"lines 6009.msd";"application/octet-stream";"TRUE > <--- I'm not sure I understand this formatting here. Is this data exported from the database, or is this content from emails? > I would appreciate advice on the attachment problem or a way of storing them > to safeguard their loss. Obviously this is a very serious problem, and a fix will be given the highest priority. We do have extensive testing of the mail retrieval section of the code, although attachments are not covered in significant depth there. Would it be possible for you to open a bug on SF for this, and add some example attachments which appear to have been lost. This will make a big difference on the time it takes to investigate this issue. If you are concerned about data loss, I would advise that you set up your front end mail server to store duplicates of incoming mail to a separate mail spool. From version 2.1, you can safely redeliver messages into MailManager and not obtain duplicates in the system. The patch for this should be trivial to add to 2.0. Regards, Kevin -- Kevin Campbell Logicalware Ltd GPG Key: F480EC23 |
From: Ron G. <ro...@fo...> - 2006-06-12 00:45:12
|
Kevin, Encoding is Latin1. The format in the appended lines were a copy of the mm_attachment table rows for some of the offending attachments. The values showing "''" are those which are returning 0 bytes. There are 2 rows which also show the same attachment file type "lines 600.msd" but in each case have a different application type stored in the Db. I have since found out that some of these files were also part of the migration from 1.1.2 to version 2. Consequently I have copies of the files from the old server (1.1.2) which I will attach to the bug report. Our mail is currently retrieved using the GetMail script via cron. Ron -----Original Message----- From: Kevin Campbell [mailto:ke...@lo...] Sent: Friday, 9 June 2006 5:50 PM To: Ron Goodwin Cc: Mai...@li... Subject: Re: [Mailmanager-users] Attachments lost - 0 bytes On Fri, Jun 09, 2006 at 10:56:21AM +0800, Ron Goodwin wrote: > > I am using 2.0.10 with Postgres 8.0 backend. We have found that a great many > of the attachments received are showing up as 0 bytes and have basically > disappeared. Since there is no way of retrieving these files, it is of some > concern. Generally, it is prevalent in pdf or in one support request all > .hmd (our proprietary format) files. > > When I look at the database table (mm_attachment) the record has a body > field of '' Ron, What encoding is your database currently set to? Connecting to the database using the psql command line client should show this when you do \l+ > Some files are also being stored with the incorrect content_type e.g. > > 40103;"2140";"6950";"lines > 6009.hmd";"application/octet-stream";"TRUE";"''";"FALSE" > > 40104;"2141";"6950";"lines 6009.msd";"application/octet-stream";"TRUE > <--- I'm not sure I understand this formatting here. Is this data exported from the database, or is this content from emails? > I would appreciate advice on the attachment problem or a way of storing them > to safeguard their loss. Obviously this is a very serious problem, and a fix will be given the highest priority. We do have extensive testing of the mail retrieval section of the code, although attachments are not covered in significant depth there. Would it be possible for you to open a bug on SF for this, and add some example attachments which appear to have been lost. This will make a big difference on the time it takes to investigate this issue. If you are concerned about data loss, I would advise that you set up your front end mail server to store duplicates of incoming mail to a separate mail spool. From version 2.1, you can safely redeliver messages into MailManager and not obtain duplicates in the system. The patch for this should be trivial to add to 2.0. Regards, Kevin -- Kevin Campbell Logicalware Ltd GPG Key: F480EC23 |