"Save All" for same-named attachments defaults to only one saved file

[Matthew Paul Thomas]

thunderbird 1:24.2.0+build1-0ubuntu0.13.10.1, Ubuntu 13.10

1. Send yourself a message containing more than one attachment with the same filename, e.g. "image.jpeg".
2. Open the message in Thunderbird, and choose "Save All".
3. Select a folder to save the attachments in, and choose "Open" [sic].

What happens: For n attachments, n–1 "Confirm" alerts appear with the text: "{pathname} already exists. Do you want to replace it?"

If you choose "Cancel", a "Save Attachment" dialog appears for choosing a different path/filename.

But the default is "OK", and if you choose that each attachment overwrites the previous one, something that nobody would ever want.

[Matthew Paul Thomas (mpt)]

Thunderbird 24.2.0, thunderbird 1:24.2.0+build1-0ubuntu0.13.10.1, Ubuntu 13.10

1. Send yourself a message containing at least two attachments with the same filename, e.g. "image.jpeg".
2. Open the message in Thunderbird, and choose "Save All".
3. Select a folder to save the attachments in, and choose "Open" (bug 531777).

What happens: For n attachments, n–1 "Confirm" alerts appear with the text: "{pathname} already exists. Do you want to replace it?"

If you choose "Cancel", instead of cancelling, a "Save Attachment" dialog appears for choosing a different path/filename (bug 678345).

However, the default is "OK", and if you choose that, each attachment overwrites the previous one that was saved just a fraction of a second earlier -- something that nobody would ever want.

Not to be confused with bug 448580. Optionally letting you specify a different name for each attachment would be a slightly faster workaround for this bug than just saving all the attachments individually. However, it would not fix this bug, which is that the *default* behavior for "Save All" is to save only one of the attachments. That shouldn't even be an option.

[Originally reported as <http://launchpad.net/bugs/1261351>.]

[Mkmelin+mozilla (mkmelin+mozilla)]

Well, bug 678345 would fix it.

[Matthew Paul Thomas (mpt)]

The solution currently proposed in bug 678345 seems targeted at a different case, where an attachment filename conflicts with pre-existing files in the destination folder. "Skip" would be what you want in the case of "I know you've been working on these files, but I forgot to send you all of them". And "Replace" would be what you want in the case of "I didn't send you all the files last time, here's an updated set".

But that would not fix this bug. Whether the default button was "Skip" or "Replace", the default behavior for same-named attachments would *still* be for only one of the attachments to be saved! "Skip" would save only the first one, and "Replace" would save only the last one. And if "Rename" was the default button, that would again nearly defeat the purpose of "Save All", not to mention being on the wrong side of the dialog.

It's possible for the two cases to happen simultaneously -- for some attachments to have the same filename, while either those or others have the same filenames as pre-existing files in the destination folder. For example, someone on an iOS device might mail you several "image.jpeg" photos in one message, then several more "image.jpeg" photos in a second message, which you save in the same folder.

Therefore, the cases can't (or at least shouldn't) be handled with separate dialogs. Nonetheless, I think the solutions are different. The solution for pre-existing files is the dialog, because their filenames may be important to preserve. But the solution for same-named attachments is just to choose a unique name automatically, no questions asked. Having the same name means that the filenames were not important (or that the paths need changing post-save anyway), so there is no point in asking before choosing a unique name.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Rochelle Rochelle (rochellerochelle4)]

So you had time to go through like 3 (THREE!) full major UI redesigns since this was first posted, but *this* was low priority to you? This thing that people actually need? With a "fix" that wastes people's time?