Bug 15844 – Downloads get date modified date in the past

• Component: Page Loading
• Status: CLOSED INVALID

[Tony Crockford]

It appears that files downloaded are date stamped using the Last Modified HTTP Header, rather than using the system date (now) to mark the file as downloaded *now*

phpMyAdmin creates it's own last modified header, set to the date of installation and therefore files downloaded using Safari from phpMyAdmin have incorrect dates for date modified.

file download last modified date stamp should be *now* as per the system, not the http header, which could easily be spoofed.

this has an importance regarding back ups and file sorting.

[David Kilzer (:ddkilzer)]

Thanks for the bug report, Tony!

Do you have any publicly available download links that demonstrate this issue?

[Alexey Proskuryakov]

I've always found it very helpful that downloading preserves file date.

phpMyAdmin behavior as described sounds buggy, because it's unlikely to work with proxies anyway.

[Tony Crockford]

you can test this behaviour for yourself at the phpMyAdmin site demo:

http://www.phpmyadmin.net/home_page/demos.php

each of the demos will give you a different date.

Safari shouldn't be using the headers, surely?  a file downloaded today is modified today...

and these files are created at the point of download, so it's even more important not to use the http date?

(I'm not sure exactly how phpMyAdmin affects it to be honest, I was surmising the date creation, but it does appear to create a header that isn't *now*)

all that said, should the browser be setting file modified dates at all?  surely it should be left to the OS to decide what date the file was modified?

[Alexey Proskuryakov]

(In reply to comment #3)
> Safari shouldn't be using the headers, surely?  a file downloaded today is
> modified today...

In OS X, that's file creation time, which should be set to the time a local file was created. The semantics of modification date match Last-Modified header perfectly.

I think this bug is INVALID.

[Tony Crockford]

(In reply to comment #4)
> (In reply to comment #3)
> > Safari shouldn't be using the headers, surely?  a file downloaded today is
> > modified today...
> 
> In OS X, that's file creation time, which should be set to the time a local
> file was created. The semantics of modification date match Last-Modified header
> perfectly.
> 
> I think this bug is INVALID.

I download a mysql database, created in Safari now and it uses a date from the past.  The same file downloaded in Firefox, from the same online application uses the date now.

Safari is in error, by using the wrong date, or by changing the date to the http header, if that's where it's coming from.

it's a bug, it's demonstrable.

makes Safari useless if the date of file download is unreliable.

sorry.

> 

[Tony Crockford]

(In reply to comment #4)
> (In reply to comment #3)
> > Safari shouldn't be using the headers, surely?  a file downloaded today is
> > modified today...
> 
> In OS X, that's file creation time, which should be set to the time a local
> file was created. The semantics of modification date match Last-Modified header
> perfectly.

except if you download an image from a page it sets the modified date as now, rather than the date the image was last modified on the server, so it's not preserving original file dates at all. and if you are using an application to create a file for download, that should be the *now* date too, shouldn't it?

[Mark Rowe (bdash)]

This is not a WebKit issue.  Downloads are handled by other layers of the system.

[Mark Rowe (bdash)]

<rdar://problem/5584136>

[Tony Crockford]

(In reply to comment #7)
> This is not a WebKit issue.  Downloads are handled by other layers of the
> system.
> 

But the same system, with a differnt broswer does not exhibit the same problem.

demonstrably an issue only when using webkit (or Safari) but not Firefox.

explain?

[Mark Rowe (bdash)]

Firefox uses it's own networking layer.