... setting the current date and time into both the creation and modification date of the file.

To my knowledge creation and modification date of a file is a function of the local file system. That information get's lost when a local file is attached to an email.

So I'm not sure what date you'd like to see, other than the current date and time, when the recipient saves the file to the local disk again.

Possibly putting the file(s) to be sent as an attachment into a zip archive, and attach that instead, would preserve the original date and time. I haven't tried this though.

Thanks for your input.

I agree that the local file system is responsible for setting these values, but no OS that I am aware of allows you to only write the current date and time.

• Your example of the zip file is a case in point. When one restores a file or directory, the zip program (with the user's ID and privileges) is allowed to create the restored files and directories with the original dates.
• A local file copy or move would be another - you would expect the date and time to be preserved because you haven't "created" a new file you're simply moving it around and the dates/times are about the file and content.

I disagree that attaching a file to an email "loses" these dates.

While I haven't looked at mail specs and metadata for a long time, on a practical level the evidence is that this is retained -

• I've been performing the aforementioned housekeeping activity for a large number of years and I've used various email clients, including outlook express, outlook, Lotus Notes and a couple of other odd ones.
• I've got several suppliers who use whatever email client or autogeneration of email that they use (so I've no control) and the files they have sent me for the last 10 years when saved locally all had the actual creation and last modification dates preserved. ...until I switched to Thunderbird.

I like TB, it's very capable, and I've invested time to get to know and be able to make it work for me so I don't want to switch again but I do need to be able to overcome this if at all possible.

Rgds, Rick.

You may want to raise a bug in Bugzilla. https://bugzilla.mozilla.org/

Well, that was a voyage of discovery. Raised bug as suggested. There's nothing close in there that I can see.

Let's see what occurs.

Thanks.

Can you post the bug ID here? Thank you.

Sure

https://bugzilla.mozilla.org/show_bug.cgi?id=1534142

I think your bug report is a duplicate, but which bug to mark as duplicates of which is the issue.

Either https://bugzilla.mozilla.org/show_bug.cgi?id=531353 or https://bugzilla.mozilla.org/show_bug.cgi?id=277405

Matt, thanks for stopping by here. Seems a better place for more detailed discussion where it's opinion than in the bug report. Although I have already asked a question there in response to your last comment about getting access to Mime data from the client, to aid workarounds in the meantime.

Again apologies for not finding those two bugs. My search for Thunderbird must have excluded them. Presumably Mailnews Core was the forerunner of Thunderbird or is an underlying component.(Any simple block diagram anywhere of how this and Firefox are constructed - for the interested but non-coder?)

Couple of observations:

277405 is marked as an enhancement. This seems strange, given that it's not conforming to standards. Perhaps historically it was an enhancement to get to RFC2183 if that came later, but surely today it should be regarded as an error, albeit I suspect minor by comparison. However as I don't know how categories are used...

On the surface something in mail, as opposed to Firefox would seem to be logical, as this is for Thunderbird.

Not that I am likely to be able to do anything myself (though I could always have a go) a workaround for Thunderbird might be an add-on that actaully performs the save but does so looking at the header info. and using it when saving the file. Presumably the support org. isn't geared up for providing this sort of help, so where to start looking for add-on devs who could help with info?

Thanks, Rick.

FYI Stuff.

There are three main applications that variously share a code base. Sea Monkey Firefox and Thunderbird. All are built on what Mozilla used to call Geko

There is history, that Netscape handed over their browser and it become Firefox. But first is became Mozilla suite. The suite had both a browser and mail client in the single application. The foundation (I think it was before there was a Mozilla company) at the time made a decision that they would move to a browser and a mail client and separate the two products. Following some agreement and disagreements the sea monkey project was born and continues to release the "Mozilla Suite" as Sea Monkey. https://www.seamonkey-project.org/

Firefox was cut out of the "suite" as was Thunderbird But as you might guess the three applications shared a huge amount of code which is were these odd bits come from. I have never rally got my head around which "bit" belong with which. But core is Firefox developers but shared with us and sea monkey. Historically it has included the add-on manager, security certificate manger password manager and the like as well as the actual rendering engine

So to my conundrum. If something in "Core" then it is something that MOCO (The Mozilla company that produces Firefox) is generally expected to fix, but it is acknowledged that others are involved. If it is Firefox, even if they fix it the change will not filter through to Thunderbird through shared source.

The reality is Mozilla ceased mainstream development of Thunderbird some five years ago. The project is now funded almost entirely by donations from users, so we do try and get as much fixed in core by the better funded folks as we can. The flip side here is we have no real control over core issues. someone can code a fix, but it requires someone from Firefox to review and accept the change. If it is not on their forward plan that can be a slow thing to get going.

You wondered what a browser would be doing with mime types. It is the same as for a mail client. if you go to download a file, the browser takes actions and opens dialogs specific to the file type. the file extension is not the stimulus of that action except as a final choice, mimetypes are.

Your observations... it is an enhancement, because the product needs to be enhanced with the functionality. It is not a case of being broken, it is a case of never implemented.

I don;t really have a solution for you, only more conjecture. Lets see what we hear in the bug. That will perhaps define some of the pathways. I would have assumed there was an add-on for what you ask, but I could not locate one. Have you looked?

Thanks for the info again. Nice to understand a bit more.

OK, see what happens to the bug report.

Meantime, yes I did have a look but the only ones I could find that might have got round it are all quite old and no longer maintained. I guess attachments in the early days weren't so well served and addons were needed.

Being optimistic I then looked for source code and this wasn't as easy to find, although I did manage to find and download an XPI of attachmentextractor for TB. I also found a few possibly related ones for rewriting the content-disp fields in Firefox but couldn't work out how to download those they all seemed to want to install, which isn't what I want. Guess that's what simplification for non-techy users delivers - what 99% want!

That's where the optimism stopped! Having gone into the js for attachmentextractor I found the usual scenario. The casual coder needs first to understand an awful lot about the environment and then how the coder has used this, then would need to understand the internal product changes between the time the code was created and today. Doing that properly (while also in my case adapting to coding in js) will take a lot of time and effort that sadly isn't available to me at this point.

Hey ho. But again thank you for taking the time to clarify things.