6.0.0-beta1
7/27/25

[#3230] download all as zip under IE.
Summary download all as zip under IE.
Queue IMP
Queue Version 4.0.4
Type Bug
State Not A Bug
Priority 1. Low
Owners slusarz (at) horde (dot) org
Requester tdrewry (at) bu (dot) edu
Created 01/07/2006 (7141 days ago)
Due
Updated 03/20/2006 (7069 days ago)
Assigned 01/12/2006 (7136 days ago)
Resolved 02/01/2006 (7116 days ago)
Github Issue Link
Github Pull Request
Milestone
Patch No

History
03/20/2006 06:18:07 PM josephmalone (at) higlum (dot) com Comment #8 Reply to this comment

[Show Quoted Text - 29 lines]
I had this same proble.  The above code fixed it for me.


02/02/2006 11:03:33 PM Michael Slusarz Comment #7 Reply to this comment
There is a bug in IE with certain type of characters in binary data 
(mainly the 'slanty' single/double quotes that MSWord uses) that we 
work around when uploading these files.  However, there isn't much we 
can do when downloading other than tell you to update windows (if this 
is indeed the problem).
02/01/2006 06:15:44 PM Jan Schneider Comment #6 Reply to this comment
No.
02/01/2006 06:08:59 PM tdrewry (at) bu (dot) edu Comment #5 Reply to this comment
my apologies.  I am working to find a non-secure document which
exhibits this problem.
[specifically]

I have two files which I know cause the error mentioned in this bug 
report.  However, both of these files contain quotes product which the 
original sender considers to be confidential.  I have tried modifing 
these files so as to not include any of the confidential data, but 
then when resaved they work correctly.



Any ideas?
02/01/2006 06:05:41 PM tdrewry (at) bu (dot) edu Comment #4 Reply to this comment
my apologies.  I am working to find a non-secure document which 
exhibits this problem.
02/01/2006 05:57:57 PM Jan Schneider Comment #3
State ⇒ Not A Bug
Reply to this comment
No feedback.
01/12/2006 05:17:00 PM Michael Slusarz Comment #2
State ⇒ Feedback
Reply to this comment
Could you provide an example message that causes an invalid name to be 
generated?  I'm guessing this might be due to (buggy) IE behavior or 
us possibly not encoding the filename in the correct manner.
01/07/2006 05:21:14 AM Chuck Hagenbuch Assigned to Michael Slusarz
State ⇒ Assigned
 
01/07/2006 03:11:55 AM tdrewry (at) bu (dot) edu Comment #1
Priority ⇒ 1. Low
Type ⇒ Bug
Summary ⇒ download all as zip under IE.
Queue ⇒ IMP
State ⇒ Unconfirmed
Reply to this comment
Found that when running under Internet Explorer certain attachments 
will fail to be named correctly by the view.php scripts download_all 
option.  Instead of $zipfile = trim($headers->getValue('subject')); 
returning a useable name, a seemingly random 6-8 character name is 
generated.



Subsequently the if statement which appends the .zip to a file name 
fails and causes the file to be saved without an extension.  While 
this does not compromise the archive, it does cause confusion to some 
users.



Finally, when using the download all with multiple PDF attachments, I 
have observed that an attempt to save the file returns an error 
message of "The file is corrupt or contains no data".



As a patch I added the following lines to view.php after

"$zipfile = trim($headers->getValue('subject'));":



     if ($browser->getBrowser() == 'msie')

         $zipfile = _("attachment");



and before

"if (empty($zipfile)) {

         $zipfile = _("attachments.zip");

     } else {

         $zipfile .= '.zip';

     }"



Under firefox the original function works correctly.

Saved Queries