attachment file dates not preserved when saving
Categories
(MailNews Core :: Attachments, defect)
Tracking
(Not tracked)
People
(Reporter: bugz, Unassigned)
References
()
Details
Environment
Using 60.5.3 on Win 7. Auto updates. This also happened with prior versions. (Can't be specific which but I've been using Thunderbird as my primary email client for about 10 months.)
Steps
Save an attachment to local (or network) disk using the save options at the bottom right of the message window or the message preview window.
Actual Result
The newly created file has associated date created and date modified info set to the time at which the attachment was actually saved.
i.e. it ignores any information sent along with the file which I think is normally held in the Mime content disposition fields.
Expected result
The newly created file should have the file dates set in line with those transmitted with it.
*** Further info***
This behaviour is out of line with other email clients that I have used (Outlook & Express, Lotus Notes, and a couple of others)
I believe that it's not conforming properly with the Mime content-disposition header fields.
It's an issue for me in that I receive a significant number of files via email that I need to file annually for legal or financial reasons. They come from a variety of sources and are often named according to the source organisation's requirements, but they all arrive with appropriate time info in the form of the file dates, which makes storing and retrieving them relatively easy as they provide context.
I'm easy as to whether the fix is to correct the behaviour or to provide an option in settings somewhere that can deliver this behaviour.
Of course if there's no data in the header then this is a reasonable approach.
Thanks for your consideration.
I would say this is a duplicate of the core bug 531353
However, lets see if we can get a second opinion.
Jorg. I would have duped this, but it looks like the Firefox folk are playing some sort of shell game with it being Firefox or Core. I would have thought Core, but what do you think? Is this a dup on a core issue? or a Thunderbird issue? Or is Bug 277405 the true Dup or it to a dup to bug 531353 as well.
Thanks for the prompt triage guys. Amazing response for a "free" piece of software. Better than most commercial support I've had as an IT manager over the (many) years.
Apologies I didn't spot those two bugs you refer to but as a user I was searching for Thunderbird only, missing the fact that the products have much in common etc.
From the description the issue is very similar (tho' I have no idea why a browser is using Mime headers). Whether the root cause is the same, or the solution etc. is something else and over to you.
Presumably, based on the age of that bug I should probably find at least a medium term workaround for my own purposes?
In that respect, for a workaround, being able to manually rename the saved attachment at point of save would be the least intrusive and least effort solution, but to do that the date info needs to be available to me. Are there any "easy" ways to view the mime fields of attachments from within the Thunderbird client?
|
||
Comment 3•6 years ago
|
||
Bug 277405 and bug 531353 and this one here are all same. TB doesn't read or at least doesn't honour those headers. The file is created with the date/time of the creation and the file dates are not set to what those headers say.
I have to admit, I wasn't even aware of those headers. As a programmer I think files should be created with the time of creation, not some past date. But the RFC proves me wrong. Setting a day in the past will then make it impossible to answer the question: When did I receive and store a particular document. It's funny because even the Linux "cp" copy command, unlike Windows, sets a new file date.
Workaround: On Windows I use a utility "Change Attributes" that lets me change various file attributes incl. creation dates. Messy.
Jorg,
Thanks for your suggested workaround. Unfortunately that wouldn't work, because I'm receiving the files and processing them at an undetermined time later, so not only would it be tricky to use such a utility, it's going to be difficult to know the actual date the file was produced (so that I can change it back to that) because I can't see that in the email client where it's stored, ...back to the question about can one see the mime header of an attachment?
Don't want to make this protracted, as you will have better things to do, but we all work with compute technology in our own way. I cut my teeth on PDP-8's & 11's for interactive computing so I've seen people get bogged down quite frequently in their own ideas. Point is, inmy experienc, that RFC is supporting something very, very common in the way people use files. A large % of folk find document management of whatever flavour far too cumbersome for their busy lives despite the best efforts of many to make them easy. So files and their dates remain a solid fallback. I'd therefore urge some consideration of that perspective whether you believe that it's wrong or that there's a better way out there.
Finally, you made me think when you talked about cp. I use Linux wherever I am able, and I like the command line, but I'd never noticed that cp timestamps in the way you describe. I then got to thinking, I use the command line as an administrator, not worrying too much about dates etc. (although that might explain one issue I had...) As a user, I use the GUI, so having confirmed you are right about cp, I tried the same in the file manager that comes with Mint Cinnamon (Nemo) as I use that regularly. It doesn't work like cp, but preserves the original time stamps. Probably why I never noticed, because that's the environment in which I organise "user files" where I take note of such stuff as file dates. I just assumed all copies were the same on the system.
Anyway, thanks for the effort you guys put into creating great software. Long may it continue.
|
|
||
Comment 5•6 years ago
|
||
Hi, old bugs like bug 277405 are a problem. Basically you need to find someone to implement/fix them since this is an open source project. Or lobby it so it gets some attention.
We also have a "TB enterprise" mailing list, https://mail.mozilla.org/listinfo/tb-enterprise, which might be a good way to lobby this.
The missing functionality is not easy to implement. When saving the file, you need to get the headers and then do a platform specific system call to set the date. We support Mac, Linux and Windows. In some cases the Mozilla platform already has a software layer in between the application code and the operating system that does the function. I'm not sure about setting file dates. Well, I looked, there is nsIFile.lastModifiedTime which is also a writeable attribute, so yes, it can be done.
Since you already got my attention, let's spread the word a bit bu asking some people.
Magnus (technical manager), do you think this could be put onto the schedule?
|
|
||
Comment 6•6 years ago
|
||
Hi Sherman, would bug 277405 be something you'd be interested in?
|
||
Comment 7•6 years ago
|
||
I'm not convinced this is a bug at all. Besides potentially confusing, it's letting the sender (who might not be trusted even) decide what timestamp to put on a a file you save. That's not usually a great thing.
|
|
||
Comment 8•6 years ago
|
||
Well, there's an RFC (which I haven't read). We're just ignoring that?
Both
thank you for your interest. The RFC (for email content-disposition in MIME) is 2183 which is of course here: https://www.ietf.org/rfc/rfc2183.txt
I don't think that everyone would find this behaviour confusing. It happens in other clients and is also in line with other user applications. I would say that it's more confusing for users when clients don't follow accepted standards, so that results differ when one uses different devices or in different environments (e.g. business or home)
The point of the RFC is that email can be used at a simple level to transport files and that includes the creation modification and read dates. Though whether many OS actually use read date/times is debatable and probably only the paranoid user would want them, but that's not for us to decide.
You ask whether the sender should decide what timestamp is on there. It's not actually the sender that sets the time, it's the OS and activity on the file that has set this, the sender is simply attaching it to an email to transfer it to a remote user who then has the option of saving it to another, unconnected file system. Both sender and recipient rely on their email clients to handle this correctly.
You suggest that the sender might not be trusted and therefore that there might be a security issue.
On a practical level if I don't know who sent me an email or I don't trust them then I'm certainly not going to place the file in my file system however this isn't because of the timestamp, it's about the content being potentially damaging. For me security is about my approach to risk and having effective malware scanning in place. I wouldn't expect my email client (or file copy) to be built to perform security functions.
Lastly, going back to the date times and what they represent.
Creation - when it was actually created and content put in it.
Modification - when the content was last changed.
Read - when the content was last accessed.
These are all in the context of the file and what's in it. i.e. the user's view, not that of the file system bucket that you are storing it in at the time.
So when you create a copy of a file, yes, it is physically a new file, but from the user's perspective it hasn't changed at all, i.e. it was still created, modified and last accessed at the same time. A user therefore would not expect the software performing the transfer to change these values.
|
|
||
Comment 10•6 years ago
|
||
(In reply to Jorg K (GMT+1) from comment #8)
Well, there's an RFC (which I haven't read). We're just ignoring that?
All the RFC says is that if an agent want's to transmit that information it MAY do it this way. So sending it is optional, and making any use of it is not in any way required by the RFC.
|
||
Comment 11•6 years ago
|
||
(In reply to Magnus Melin [:mkmelin] from comment #7)
I'm not convinced this is a bug at all.
We have RFC for headers and it is clearly the intention that a client can do something with the information provided. At the very least we should implement it and provide an UI to turn the option off if individuals have issues with using the information as described in the RFC. But selectively choosing which parts of RFC's to implement based on our personal views is not a good idea. At the very least this is a requiest to make the product RFC compliant, so it is a bug. That the item has been floating arounf for 14 years since first being raised is more a reflection on Mozilla for their failures in RFC compliance. I would like to think Thunderbird is more interested in open standards and RFC compliance.
We have been tendered a good use case where having the original dates is a good idea. Tax records. As there are lots of accountants and their clients using Thunderbird, that should be enough to make implementation a plus. Given the increasing difficulties folk have sending Zipped attachments, it is no longer a good way to transfer data between users.
|
|
||
Comment 12•6 years ago
|
||
Can and should are two different things. All the rfc says is that (when sending) "The creation-date parameter MAY be used to indicate the date at which the file was created."
MAY == strictly optional, if that wasn't clear.
But down to business: I've never encountered this usage in the wild. It does have privacy implications in certain cases, and like said earlier, will cause potentially unexpected behaviour. I know I have such files sorted in date order newest on top and would likely not find what I'm looking for if the date is unexpected. So in short, I don't see why it would be any priority, if a bug at all.
|
||
Comment 13•6 years ago
|
||
When saving an attachment from:
- Gmail (in a browser)
- Apple Mail
- Airmail
- Postbox
None of them save the date created and date modified info from the file. So I suspect there is less expectations that they will be preserved.
On our end, we've received perhaps one or two requests for this in Postbox.
|
||
Comment 14•6 years ago
|
||
Do you also see this issue when using versoin 68?
|
Reporter | |
Comment 15•5 years ago
|
||
Yes. This issue is still current for me.
Using previous 68 version and today's rcvd update to Version 68.4.1. Both have saved attachments where the file was created on 1/11/19 and 2/12/19 (from content of doc) and sent to me respectively on 2/11 and 3/12. Saved both attachments today and these were saved with dates of 23/1.
All dates local UK GMT.
|
|
||
Updated•5 years ago
|
|
||
Updated•3 years ago
|
Description
•