1736194 - Since 91.2.0 every email I save has superfluous data added to the filename

Status: NEW

(Thunderbird :: General, defect)

Description

[Edward Tomchin]

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:93.0) Gecko/20100101 Firefox/93.0

Steps to reproduce:

I did nothing but accept the 91.2.0 update after which every email I save has extraneous data added to the filename I give it which fouls up my archive. I then have to delete that extraneous data or my archive (currently 2,136 unique folders containing 725.7 gigs of data) will not result in correct responses when searched due to that added data.

Actual results:

When I click on an email to save it, this filename is given to it by Thunderbird
Bugzilla confirm account creation - 'Bugzilla@Mozilla' ([e-mail]) - 2021-10-16 1741

Expected results:

This should have been the resulting filename
"Bugzilla confirm account creation"
which I then save as an html file. As it is, I have to delete that extraneous data from each file I save, which amounts to quite a bit of extra work. I frequently receive more than 100 emails a day. Please remove the code that does this and issue a new update (or tell me how to revert back to my former version of TBird. Thank you

Comment 1

[Alfred Peters [:infofrommozilla]]

Per Bug 1722223 comment 5 this is a WONTFIX.

I'm not sure about the bug component but "preferences" doesn't seem correct to me.

Comment 2

[Matt]

I think the comment in Bug 1722223 was a little aggressive, especially for something in an ESR release. Of couse a pref was required.

See https://support.mozilla.org/en-US/questions/1354274
and
https://support.mozilla.org/en-US/questions/1354530

For other less than pleased users.

Perhaps the structure of file save as can be modified to allow the user to specify what they want defaulted. Perhaps in a similar way we used to allow users to customise print header information. Until then a pref is needed to allow a customisation string to set the filename, similar to that offering in the importexportNG addon for saving EML files.

Comment 3

[Magnus Melin [:mkmelin]]

The ImportExportTools NG add-on provides customized file format, for those who would like that

Comment 5

[mail]

(In reply to Magnus Melin [:mkmelin] from comment #3)

The ImportExportTools NG add-on provides customized file format, for those who would like that

Thanks for the suggestion, I tried that and in principle, it seems very handy to me.
Unfortunately, it doesn't fulfil all my requirements.
My main issue is that I need to add information to the filename that cannot be automated.
With the addon, the save dialogue does not offer to further adapt the generated file name, you can only select the folder to save to.
I would then need to manually navigate there and then adapt the filename, which is more tedious than deleting the superfluous information added by TB itself.
I could not find an option to change that, I'll also provide this feedback to the developers of ImportExportTools NG.

Comment 6

[andreas.damsky]

I have also tried the ImportExportTools NG and it is not useful for my workflow.
Normally I use the key combination "CTRL-s". The addon has no influence on this, and the way to save via mouse-clicks is cumbersome.
It would be nice if the config-editor could be used for this purpose.

Comment 7

[Edward Tomchin]

I doubt this is a bug, but rather an addition to our email addresses that benefits Mozilla and no others. There is no user I know of this addition benefits and know of many whom it irritates and discourages. Mozilla ought to pay more attention to satisfying it's users than benefitting itself at the expense of these users.

Comment 8

[Peter]

This is a change to previous functionality. It certainly pleases some people (ref. https://bugzilla.mozilla.org/show_bug.cgi?id=1722223) but with 90+ intervening major releases between "Thunderbird original" and this release, perhaps it should have been made optional?

Or if for some reason it was deemed necessary "logical" default behavior then at least supply a preference to revert to the original file naming behavior?

We are just users of this product. We aren't devs and shouldn't have to chase down how and why changes were made, what happened, how to handle workflows now that someone else has decided to "fix" something that truly was not broken... Please give us a choice here devs!

P.S. "Fix it with an extension" is not a fix.

Comment 9

[Edward Tomchin]

I'd even be satisfied with an extension that removes that unnecessarily added data to each filename.

Comment 10

[WaltS48 [:walts48]]

What am I missing?

When I save a single email like this one, my File Manager opens, and I can give the file any name I want.

If I was to save it, I would shorten it to "[Bug 1736194] Since 91.2.0 every email I save has superfluous data added to the filename.eml", removing the "Bugzilla@Mozilla" <[e-mail]> - 2021-12-05 2234".

The user has a choice.

Comment 11

[mail]

(In reply to WaltS48 [:walts48] from comment #10)

What am I missing?

Let me quote from the original entry:
"As it is, I have to delete that extraneous data from each file I save, which amounts to quite a bit of extra work."

=> A lot of users liked the export as it was before the extra info was added. It is "cumbersome" to manually remove it (and yes, there are obviously use cases where it is necessary to do that).
We would like a choice to decide whether this extra info is automatically added or not.

Magnus Melin suggested that these users try the ImportExportTools NG add-on, but that does not help.

For details, please take the time to read the other replies!

Comment 12

[Edward Tomchin]

Well, I give up. Mozilla has outlived it's purpose and usefulness, including Thunderbird and Firefox (which has more issues beginning with update 56.0 than it's worth). I've already started using a different browser. Now I'm looking for a different email client.

Comment 13

[Peter]

(In reply to WaltS48 [:walts48] from comment #10)

What am I missing?
[...]
The user has a choice.

"The user" has always had a choice in naming saved files. What you are apparently missing is that this is an intentional change in save functionality which changed the default filename, which means the change should have at least been noted in the public Revision history for the product. So non-technical users did not need to comb through the bug repository to find out what happened, and ultimately determine that this was not a bug but indeed an intentional change...

I won't waste any more time or bandwidth on complaints as they don't really belong in a bug repository either. However it would be nice if Mozilla could offer up some sort of forum where new ideas can be vetted by the user base at large, before they are implemented as quickly as this change was, with feedback from essentially only one user prior to the code change (ref. bug 1722223). No offense intended towards that user as he certainly tried to suggest the use of a preference setting to control this behavior.

Comment 14

[Matt]

I think the issue here is the original proposal offered to have the old and new file names a user preference. All I see this bug asking for is that the original proposal for a pref to revert to the old convention be implemented.

I am sure having a user string where the user could specify which parts of the email should be in the name is a better option. But really all this discussion is over the original decision to remove the pref to retain the original behaviour. Perhaps like our modernised printing and profile import/export more though was needed into the actual process and implementation befroe the code was approved.

Comment 15

[Anje]

AS it was an intended change, it cannot be a bug.
However, changing a default forcing long filenames on users or manually edited everything you save is not going to appease everyone.

I automatically looked in Preferences to see if an option had been created to choose original or new filename settings.

Example - In support forum a user tells us:

Ever since I upgraded to Thunderbird 91 the 'message sender' and 'message date' are automatically appended as a suffix to the default filename(the message subject) when using the save-as command to save an email in the '.eml' format. This causes problems when attaching the '.eml' file to one of the software packages that I must use.

It would have been better received to offer eg: short (Subject+date) or long format (Subject+sender+date) options.
The options offered by ImportExportTools can reduce to just Subject - so you could say the addon offers a more extensive range.

Perhaps this bug is really a request for enhancement to offer the user easy Preference settings choice for short or long format in filename.
If more is required then the addon is an option, but we should be mindful that not everyone can install addon extensions. They may not have the skillset, ability or permissions.

Comment 16

[u702298]

Another user here finding the extended string of superfluous information when saving emails cumbersome. Of course you can delete all the information and type in a new file name, but if you save lots of emails every day this gets old really quickly.

Please can an option be attached to the Save As function which allows the user to specify which file name information to include when saving emails.

Comment 17

[m]

(In reply to Anje from comment #15)

It would have been better received to offer eg: short (Subject+date) or long format (Subject+sender+date) options.
The options offered by ImportExportTools can reduce to just Subject - so you could say the addon offers a more extensive range.

Perhaps this bug is really a request for enhancement to offer the user easy Preference settings choice for short or long format in filename.
If more is required then the addon is an option, but we should be mindful that not everyone can install addon extensions. They may not have the skillset, ability or permissions.

With great gratitude for its submission, I support this suggestion. Of course, for the short format a naming with respect to minimalist/restrictive file systems would be desirable (e.g. replace spaces with underscore, umlauts with double letters, remove special characters ...) . Thanks again :-).

Comment 18

[u702298]

I added to this thread 11 months ago but no change as yet. Please can there be an option to revert back to short file names when saving emails. The overly long filename including the sender's name, email address and date makes my filing life difficult (I'm disabled).

I do sometimes use import/export tools to save files if I just want the subject, but usually I want the subject plus my own unique code for filing purposes. There is no option to do this in import/export tools as the options are fixed.

If I use File/Save As, I have to delete all the superfluous email name and date, leaving just the subject, then add my own filing code text.

It was so much easier when emails saved with just the subject, and I then only needed to add my text filing code.

I don't see how this is too much of an ask, being as though Save As used the subject only for years before the 91.2.0 update. Please bring this back as an option.

Comment 19

[Mart]

(In reply to m from comment #17)

(In reply to Anje from comment #15)

It would have been better received to offer eg: short (Subject+date) or long format (Subject+sender+date) options.
The options offered by ImportExportTools can reduce to just Subject - so you could say the addon offers a more extensive range.

Perhaps this bug is really a request for enhancement to offer the user easy Preference settings choice for short or long format in filename.
If more is required then the addon is an option, but we should be mindful that not everyone can install addon extensions. They may not have the skillset, ability or permissions.

With great gratitude for its submission, I support this suggestion. Of course, for the short format a naming with respect to minimalist/restrictive file systems would be desirable (e.g. replace spaces with underscore, umlauts with double letters, remove special characters ...) . Thanks again :-).

With great gratitude for its submission, I support this suggestion. Got a lot of trouble with the long format which exeeds 255 characters with Folder Structures. And in mixed systems using Windows and cloudstore(unix), files seem to vanish which have been stored in cloudstore and looked afterwards in Windows with the Windows file Explorer. The mentioned plug in is a first step solution, for in many cases there have to be added further information, or information of the subject has to be deleted mostly lokated in the middel of the text. The plug in only allows changes in general, not on the single action of saveing an E-mail as file. To have a choice about the Elements which are automatical used for the generation of a file name using the function cmd_saveAsFile, would be very very very helpful. As well as the posebility to choose the date format between ddmmyyyy and yyyymmdd or sophisticated, individulised out of the components yyyy, yy, mm, dd.

Comment 20

[Mark]

Had some fun today with Linux Mint and Save-As for a selected email onto a NAS location.
Under Windows the default additional fields added to an email when saved include the email address ([e-mail]) and under Linux the default additional field includes the user email address <[e-mail]>.
No useful error was returned when attempting to save the emails to the NAS, but it didn't save the email and I was lucky I figured out what was going on. The < and > are invalid characters for writing to a Windows filesystem. I had to save to the local Linux filesystem and then rename the files in order to then put them on the NAS.
This would all have been obviated by improving the user experience in terms of the default values applied to a filename when saving an email.
Why default to all the extra data?
Why not make it configurable instead?
And why would the linux version and windows version behave differently?
(I nearly raised a separate bug for this, arguably could, but this 3 year old entry suggests there's no inclination to change here?)

Comment 21

[Peter]

The way this "feature" was pushed through with apparently no real user input makes me strongly suspect that it was an "exercise" for an individual or team or dept. that needed to demonstrate its programming competency. Here we are three years later with "Priority: Not set" and "Severity" not defined, and no real explanation as to why the feature was added, and no plans announced as to how to fix its quirks and bugs. All of this tells me that the outcome of this bug report will likely be WONTFIX, but apparently nobody can be bothered to label it as such.

I finally gave up on Thunderbird's incessant "changes for change's sake" and switched to Betterbird. Have a look at the "Software Quality" section on the Betterbird homepage, which describes code quality trends in Thunderbird (essentially explaining the need for a quality oriented fork like Betterbird). It's a real eye opener!

I'll Stop Following this bug report after adding this comment. Thanks everyone here for chiming in. Hopefully someone on the dev team will eventually pick up the bug.

Comment 22

[Anje]

Support Forum:
I would have assigned a tag for bug 1736194 for the following but I cannot assign that bug number - it's not in drop down list.
https://support.mozilla.org/en-US/questions/1005019
https://support.mozilla.org/en-US/questions/1355463