Thunderbird saves double attachment file name endings on FAT32 and NTFS

Bug #485224 reported by Don Cristóbal on 2009-11-19
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Mozilla Thunderbird
Fix Released
High
thunderbird (Ubuntu)
Low
Unassigned

Bug Description

Binary package hint: thunderbird

When saving individual attachments to a FAT32 or an NTFS partition (not: menu File - Attachments - Save all), Thunderbird duplicates file name endings. E.g. it saves "draft.doc" as "draft.doc" on EXT3/EXT4, but as "draft.doc.doc" on FAT32/NTFS.
I have my Thunderbird profile on a Linux/Windows shared FAT32 partition, but I also checked it with a temporary profile on the main EXT4 partition. So the bug really seems to be in the portion of the software that saves attachments to disk.

Kind of a workaround:
If anyone needs a workaround for large numbers of attachments, here's a very primitive one:
* go to the folder where the double named attachments are
* $ rename -v 's/(\.\w{3}\w?){2}$/$1/' *
This looks for 3 or 4 character long file name endings that are duplicated and removes one copy.

I saved this single line 'script' in a file and installed it to /usr/local/bin as an executable ($ sudo install yourfilename /usr/local/bin). Now I can just cd to the concerned folder and say my magic word (the name of the script), voilà.

ProblemType: Bug
Architecture: i386
Date: Thu Nov 19 09:40:58 2009
DistroRelease: Ubuntu 9.10
InstallationMedia: Xubuntu 9.10 "Karmic Koala" - Release i386 (20091028.3)
Package: mozilla-thunderbird (not installed)
ProcEnviron:
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.31-14.48-generic
SourcePackage: thunderbird
Uname: Linux 2.6.31-14-generic i686

Created an attachment (id=281304)
Downloaded file renamed and with double extension

This also happens with other file types, at least under Windows.
To make things even worse: If you try to save a file overwriting an existing file with the same name, Firefox asks if the existing file should be replaced but instead, the downloaded file is renamed and it is given the double extension. See my attachment (Screenshot).

*** Bug 396706 has been marked as a duplicate of this bug. ***

Still present under Vista and Vista SP1 on

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9a8pre) Gecko/2007091904 Minefield/3.0a8pre

Just to clarify - is this windows only? If so, I think I see what *may* be the problem, but I'm not 100% sure still.

For my reference:
http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/uriloader/exthandler/nsExternalHelperAppService.cpp&rev=1.345#2096

Looks like it is windows only since I cannot reproduce this on my mac.

What other bugs landed in this window? I'm not really sure if Bug 395308 actually caused this...

It's present on Linux. Happened a few times for me. I just downloaded a gzip archive and ended up with .tar.gz.gz. Interestingly, it also appends .exe to any binary file -- for example, .iso.exe.

I'm seeing something odd here: http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/xpcom/io/nsLocalFileOS2.cpp&rev=1.96&root=/cvsroot#2167

There once was a return there, maybe that's the culprit. If I'm correct, this file is not only about OS/2 filename stuff?

This is about in general, though I haven't been able to reproduce it on the mac (I haven't tried a tar.gz file however).

Definitely regressed with bug 395308 because now tempFile.isExecutable() doesn't work.

Created an attachment (id=283067)
v1

Don't use this.mLauncher.targetFile.isExecutable because it'll give us the wrong information.

Append the primary extension only if it doesn't already have it.

These tryserver builds have bug 396477 and bug 396701 potentially fixed.

win32: https://<email address hidden>
macosx: https://<email address hidden>
linux: https://<email address hidden>

(From update of attachment 283067)
r=sdwilsh

Testing with WinXP Pro SP2, with Mardak test build. As far as I can tell, it's fixed.

Checking in toolkit/mozapps/downloads/src/nsHelperAppDlg.js.in;
/cvsroot/mozilla/toolkit/mozapps/downloads/src/nsHelperAppDlg.js.in,v <-- nsHelperAppDlg.js.in
new revision: 1.54; previous revision: 1.53
done

Seems to break double extension file downloading.

Try to download firefox-3.0a9pre.en-US.linux-i686.tar.bz2 from http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/

And you'll get this in error console :

Error: [Exception... "Component returned failure code: 0xc1f30001 (NS_ERROR_NOT_INITIALIZED) [nsIMIMEInfo.primaryExtension]" nsresult: "0xc1f30001 (NS_ERROR_NOT_INITIALIZED)" location: "JS frame :: file:///home/fred/Applications/firefox/components/nsHelperAppDlg.js :: anonymous :: line 219" data: no]
Source File: file:///home/fred/Applications/firefox/components/nsHelperAppDlg.js
Line: 219

Reopening and backing out the patch could be a good idea ? Because it is a big regression :(

WFM with 2007100304 and 2007100405

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a9pre) Minefield/3.0a9pre

(In reply to comment #18)
> Error: [Exception... "Component returned failure code: 0xc1f30001
> (NS_ERROR_NOT_INITIALIZED) [nsIMIMEInfo.primaryExtension]" nsresult:
> "0xc1f30001 (NS_ERROR_NOT_INITIALIZED)" location: "JS frame ::
> file:///home/fred/Applications/firefox/components/nsHelperAppDlg.js ::
> anonymous :: line 219" data: no]
> Source File:
> file:///home/fred/Applications/firefox/components/nsHelperAppDlg.js
> Line: 219
This error is garbage and is safe to ignore (see bug 393627).

But the problem stays the same. I CANNOT donwload any file ending with tar.bz2 or tar.gz :(

I'm assuming you're running linux? WFM Windows and Mac OS X -- I can't get trunk running on Linux.

sdwilsh: that isn't the handlerservice error...

I've seen that since that code landed - I was under the impression that it was the same cause...

Erh... I thought it was related to gcc 4.2 under Gutsy AMD64.

But with gcc 4.1, same problem. No file could be downloaded if it is ended like tar.bz2 / tar.gz.

Could be a AMD64 bug ?!

sdwilsh: You can't assume that a mime info has a primary extension

Sorry to say that reversing the patch makes downloading working fully and completely again.

Strange !

Frederic: Can you confirm that you're running firefox on linux -- and would you happen to be saving to a mounted drive that has the executable bit incorrectly set? (Or perhaps your umask has things created with executable set.)

biesi: If we can't grab the primary extension, we should probably still try putting on some extension to prevent the user from accidentally creating an executable? E.g., saving a .torrent file as .exe. But then what extension should we use if we couldn't get the primary extension? Take the source's?

And I suppose we could make this Windows only for bug 270159.

I am using Ubuntu Gutsy Gibbon AMD64.

$ uname -a
Linux fredo-gutsy 2.6.22-12-generic #1 SMP Sun Sep 23 20:03:18 GMT 2007 x86_64 GNU/Linux

I want to save every single download on my main partition, in a directory named download.

Here are the sets of my download directory :

$ ls -al download
total 12
drwxr-xr-x 2 fred fred 4096 2007-10-04 21:06 .
drwxr-xr-x 50 fred fred 4096 2007-10-05 10:22 ..
-rw-r--r-- 1 fred fred 1039 2007-10-04 19:59 exe.exe.patch

I'm confused; is it safe to verify this, since it's now working fine on Windows using Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9a9pre) Gecko/2007101905 Minefield/3.0a9pre, (and do we need to then spin off a bug for comment 29 and others), or are we going to address Frederic's issues here?

(In reply to comment #30)
> I'm confused; is it safe to verify this, since it's now working fine on Windows
> using Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9a9pre)
> Gecko/2007101905 Minefield/3.0a9pre, (and do we need to then spin off a bug for
> comment 29 and others), or are we going to address Frederic's issues here?
He needs to file a different bug if he didn't already. This bug can be verified.

Verified FIXED on Windows Vista; see comment 30.

This bug is fixed, mine is 398551. And it is kinda pain-in-the-*** to say the least :(

*** Bug 402006 has been marked as a duplicate of this bug. ***

Don Cristóbal (doncristobal) wrote :

Binary package hint: thunderbird

When saving attachments to a FAT32 or an NTFS partition, Thunderbird duplicates file name endings. E.g. it saves "draft.doc" as "draft.doc" on EXT3/EXT4, but as "draft.doc.doc" on FAT32/NTFS.
I have my Thunderbird profile on a Linux/Windows shared FAT32 partition, but I also checked it with a temporary profile on the main EXT4 partition. So the bug really seems to be in the portion of the software that saves attachments to disk.

Kind of a workaround:
If anyone needs a workaround for large numbers of attachments, here's a very primitive one:
* go to the folder where the double named attachments are
* $ rename -v 's/(\.\w{3}\w?){2}$/$1/' *
This looks for 3 or 4 character long file name endings that are duplicated and removes one copy.

I saved this single line 'script' in a file and installed it to /usr/local/bin as an executable ($ sudo install yourfilename /usr/local/bin). Now I can just cd to the concerned folder and say my magic word (the name of the script), voilà.

ProblemType: Bug
Architecture: i386
Date: Thu Nov 19 09:40:58 2009
DistroRelease: Ubuntu 9.10
InstallationMedia: Xubuntu 9.10 "Karmic Koala" - Release i386 (20091028.3)
Package: mozilla-thunderbird (not installed)
ProcEnviron:
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.31-14.48-generic
SourcePackage: thunderbird
Uname: Linux 2.6.31-14-generic i686

Don Cristóbal (doncristobal) wrote :
description: updated
Micah Gersten (micahg) wrote :

Thanks for reporting this bug and any supporting documentation. This bug was fixed in Thunderbird 3 upstream. I am marking it Triaged pending release of Thunderbird 3 in Ubuntu. Thanks for taking the time to make Ubuntu better! Please report any other issues you may find.

Changed in thunderbird:
milestone: none → 3.0
Changed in thunderbird (Ubuntu):
importance: Undecided → Low
status: New → Triaged
Changed in thunderbird:
status: Unknown → Fix Released
Launchpad Janitor (janitor) wrote :
Download full text (6.7 KiB)

This bug was fixed in the package thunderbird - 3.0+nobinonly-0ubuntu1

---------------
thunderbird (3.0+nobinonly-0ubuntu1) lucid; urgency=low

  * New Upstream Release 3.0 (THUNDERBIRD_3_0_RELEASE)
    - LP: #50902 - Thunderbird displays useless dialog
    - LP: #52667 - Thunderbird doesn't support RFC-2369
    - LP: #49033 - Doesn't recognize upper case extension (.JPG)
    - LP: #56465 - Per folder column widths
    - LP: #68456 - CTRL-Shift-K bound to 2 functions
    - LP: #79337 - Typo in Server Information for Add Account Wizard
    - LP: #1084 - No scroll on full headers list
    - LP: #62071 - Middle click on scrollbar pastes instead of jumping
    - LP: #119358 - Weak default authentication mode
    - LP: #120672 - No option to empty junk folder with right click
    - LP: #96566 - movemail doesn't work with default privs
    - LP: #122529 - Non-Thunderbird IMAP folders not visible to Thunderbird
    - LP: #241276 - Not able to paste image into thunderbird compose window
    - LP: #244635 - scrollboxes scroll to offset 0 when resized
    - LP: #259387 - "Edit Message as New" broken for eml messages
    - LP: #120281 - Editing a message from the drafts folder leaves line breaks
    - LP: #115484 - Dialogue boxes too large for 1024x768 resolution
    - LP: #320034 - Mail with self referencing headers breaks threading
    - LP: #160794 - shortcuts different in windows and linux
    - LP: #280987 - thunderbird keeps asking a password when working off-line
    - LP: #369150 - Thunderbird splits email addresses with non-ascii characters
                    and a comma in From: field
    - LP: #135066 - Thunderbird doesn't use Ubuntu icon theme
    - LP: #297301 - after authentication error the password is forgotten
    - LP: #487541 - thunderbird-bin crashed with SIGSEGV (AFS filesystem)
    - LP: #485224 - Thunderbird saves double attachment file name endings on
                    FAT32 and NTFS
    - LP: #482496 - When using SCIM ANTHY, autosaving fails, and then get asked
                    about sending in UTF-8

  [ Fabien Tassin <email address hidden> ]
  * Add build-depends on autoconf2.13, autotolls-dev, mozilla-devscripts
    libglib2.0-dev (>= 2.12), libstartup-notification0-dev, libbz2-dev,
    libpixman-1-dev, libdbus-1-dev (>= 1.0.0), libdbus-glib-1-dev (>= 0.60),
    libhal-dev (>= 0.5.8), libasound2-dev, libreadline5-dev | libreadline-dev,
    libkrb5-dev
  * Update build-depends minimums for libx11-dev (>= 2:1.0),
    libgtk2.0-dev (>= 2.12), zlib1g-dev (>= 1:1.2.3), libpng12-dev (>= 1.2.0),
    libjpeg62-dev (>= 6b), libcairo2-dev (>= 0.5.8), libgnome2-dev (>= 2.16),
    libgnomevfs2-dev (>= 1:2.16), libgnomeui-dev (>= 2.16),
    libnss3-dev (>= 3.12.0~1.9b3)
  * Bump standards version to 3.8.0
  * Replace ${Source-Version} by ${binary:Version} in control file
    - update debian/control
  * Bump requirement for system nspr to >= 4.8 since Mozilla bug 492464 landed
  * Bump requirement for system nss to >= 3.12.3 since Mozilla bug 485052 landed
  * Use in-source hunspell when hunspell 1.2 is not available
  * Add conditionnal support for --with-libxul-sdk controlled by
    $(USE_SYSTEM_XUL)
    - update debian/rules
  * Add p...

Read more...

Changed in thunderbird (Ubuntu):
status: Triaged → Fix Released
Changed in thunderbird:
importance: Unknown → High
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.