Closed Bug 178506 Opened 23 years ago Closed 15 years ago

save original last-modified date on file downloads

Categories

(Core Graveyard :: File Handling, enhancement)

Product:
Core Graveyard
Component:
File Handling
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX
Milestone:
mozilla1.9.3a1

People

(Reporter: logan+mozilla-bmo, Assigned: andrey.v.ivanov)

References

Details

(Whiteboard: [use https://addons.mozilla.org/en-US/firefox/addon/93121 to get the old behavior])

Attachments

(3 files, 15 obsolete files)

access_time.png
25.13 KB, image/png
Details
proposed patch
20.82 KB, patch
Details | Diff | Splinter Review
backout v1.0
13.83 KB, patch
Details | Diff | Splinter Review
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2b) Gecko/20021104 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2b) Gecko/20021104 I keep a software archive at work and it's nice to see the original file timestamps to have some idea of the original release date. Most of the time I'll just grab urls (http, ftp) from mozilla and pass them to another program (like lftp) to grab the file with the timestamp on the remote server. Somewhat odd feature request, and I have no idea if anyone else would find something like this useful or if it could end up causing alot of problems on the browser side and/or confusion for users. :I Reproducible: Always Steps to Reproduce: 1. Go to http://www.gozer.org/images/bang.png 2. Right click image (Save image as). 3. Look at the saved file's timestamp (mtime). Actual Results: File saved with current time. Expected Results: File saved with original timestamp from the server: Last-Modified: Mon, 21 Jan 2002 03:02:45 GMT
Does IE or Comm 4 do this? I think some virus checkers or other system utilities might object, but otherwise, I don't know if this would be bad in any way.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Tried NS480 on linux and IE6 on Windows. Neither did it.
Keywords: helpwanted
Target Milestone: --- → Future
*** Bug 190721 has been marked as a duplicate of this bug. ***
According to bug 190721, this is the behaviour of wget ... It gets my vote too.
Is there a standard format for the last-modified string? Do we have a parser we could reuse for it? If so, this should be simple to do (at least for http).
I rarely use a browser to download anything, precisely because browsers don't preserve timestamps. In order to manage downloaded files, I need to know how old they are, not when they were downloaded, so I use wget. It would be more convenient for the browser to save exactly what it found exactly the way it was found, just like copying a local file from one directory to another. OS -> all
OS: Linux → All
Hardware: PC → All
GNU's wget does this very nicely for ftp and http downloads. Just use the same algorithm.
We can't do that, since wget is GPLed and Mozilla can be distributed under other licenses (eg MPL). Or rather, we can use the same algorithm as long as we reinvent ourselves it without looking at their code.....
fwiw, I disagree with this bug. I often search for files I downloaded by the last modified date of them, which is the date of when I downloaded it.
You can easily change the timestamp to current upon download. The converse is not generally true, since as often or more as not, the filename is all you can select to download, without any access to its attributes. Often the only way you can find out how old the file is on the server is to use wget to download it.
This could be set as a download preferences option for those that don't want to know how old a file is or want a new timestamp on everything they download.
> This could be set as a download preferences option If we make this an option, we better not have UI for it. 99% of people could not care less about the timestamps on the files. I'm not particularly inclined to make it an option in any case. We should just pick one or the other and do it.
The preferences-downloads page looks pretty sparse and I would hate to have the ability to store the real file date not available just because some people want the current time and date put on the files.
Imo that pref panel should not even exist, imo. The only reason it does is that download manager is so buggy and broken (and on by default) the people wanted a way to switch back to the progress dialog. What we should really do is to fix download manager, remove the progress dialog, and remove the panel.
What really should be done is to remove the download manager and make the progress dialog the default behavior for downloading, but not pop up at all when I choose to save the current page to disk.
Is this the correct component? It sounds more like download manager to me.
It is supposed to be about saving web pages and downloading files and setting the timestamp on the file(s) to be the same as on the server (like wget does). I was thinking maybe a different approach could be to actually invoke wget to get any particular file and this would give the added benefit of having it automatically retrying the download and continuing it until it gets the whole file. This would be ok for files being downloaded, but saved web pages get changed somewhat to fix links to downloaded images and stuff, so wget would not work for saving pages without some extra work.
If this is going where I think this is going (make our download manager as cool as wget), it might be easier to define a "x-wget:" scheme that sends a bunch of info to wget. But sticking to the subject: bz: is there anything in this bug about getting the correct timestamp that is related to the Necko file functions? If not, shouldn't this go to download manager?
This is not a necko bug, yeah. It's file handling (not just download manager, but also persistence object).
-> file handling, per bz.
Assignee: dougt → law
Component: Networking: File → File Handling
QA Contact: benc → petersen
*** Bug 227782 has been marked as a duplicate of this bug. ***
*** Bug 233384 has been marked as a duplicate of this bug. ***
Summary: save original timestamp on file downloads → save original timestamp (last-modified date) on file downloads
On Windows (and perhaps other OS's) each file has both a creation date and a modification date. The value of the Last-Modified header could be saved to the modification field, and the actual download time to the creation field (or perhaps the other way around).
*** Bug 268647 has been marked as a duplicate of this bug. ***
This enhancement is becoming more important now that more and more "download sites" do not put direct links to files on their pages but try to send you through hoops of javascript and redirections. This makes downloading using wget ever more difficult. (right-click, copy link location, and paste that after a "wget" in a shell window usually does not work anymore... it gets you a useless HTML file)
See the "helpwanted" keyword. nsIFile exposes a lastModifiedTime attribute; it's just a matter of actually writing it in the relevant places, possibly (those places being nsWebBrowserPersist.cpp and nsExternalHelperAppService.cpp).
I wonder if channels should expose the last-modified date in form of a PRTime. Seems like nsIPropertyBag2 would expose a good way to do that :-) That said. I kinda like it that sorting by last-modified date in file managers sorts by the date that I downloaded the file on, not when it was modified on the server.
Another program, curl ( http://curl.haxx.se/ ), is also able to preserve last-modified date when using -R switch. And its license is MIT/X, which should be more liberal than GPL. Maybe mozilla can use their code.
Assignee: law → file-handling
QA Contact: chrispetersen → ian
You do realize that Mozilla is NOT GPL, right? And the problem is that people want to see BOTH dates on the file, as far as I can tell.
(In reply to comment #29) > You do realize that Mozilla is NOT GPL, right? Yeah, I know MPL, and I know that program uses GPLed code must also released in GPL. Thus I find a program not licensed in GPL (please refer to curl website), and I think that might be helpful for you if you want to add this feature. > And the problem is that people want to see BOTH dates on the file, as far as I > can tell. That's the problem, different people have different ideas. I want to preserve the timestamp, so I copy the URL to wget. However other people might only want downloaded files to be dated as download time, while most people don't care it at all... A hidden pref in about:config is enough for me, if you will add this feature eventually.
*** Bug 298042 has been marked as a duplicate of this bug. ***
*** Bug 299010 has been marked as a duplicate of this bug. ***
IE and Safari on the Mac properly preserve the modification date.
*** Bug 300703 has been marked as a duplicate of this bug. ***
I am surprised this topic is being discussed as if it were merely a matter of personal taste. There are specific activities for which preserving date information is an objective requirement, e.g. projects where it can be very important to know what has changed recently. Of course there are all sorts of ways in which people who wish to collaborate can produce tar or zip files which when unpacked will show original dates. Moreover, when I download research papers from academic web sites the date is often very important but I can't always ask the individuals to package their files for my benefit. But if firefox is to be used as a serious tool rather than just a 'noddy' tool for naive users, it should support such a need when it exists. There are also situations where there is an objective need for people to have a record of download time, though that is somewhat easier to achieve either by doing something to the file after it has been fetched, or by using sub-directories for different download periods. The other need cannot in general be met by user action, so it should be supported by the browser. I don't mind if there's a default preference that I have to change in order to achieve this.
*** Bug 308255 has been marked as a duplicate of this bug. ***
This bug is the only thing keeping me from switching from Mac MSIE. (Well, this bug and lame sites that only work with MSIE).
(In reply to comment #29) > You do realize that Mozilla is NOT GPL, right? And the problem is that people > want to see BOTH dates on the file, as far as I can tell. Actually I have never needed both, but I can see that some people might. The question is: how easy is it for people to set the dates to meet some requirement. Possible requirements: 1. Set the fetching date: easy after the file is fetched 2. Set the creation/modification date: impossible after the file is fetched 3. Record both dates in an auxilliar file: easy IF the file is fetched withthe original date. The current default supports only one of the three possible requirements. Changing the download mechanism to meet requirement 2 would make it relatively easy for those who want option 1 or option 3. Regarding GPL and wget: I don't know the details but surely wget uses some well documented mechanism for getting the date information from the remote server and some well documented mechanism for setting that date on the new file? I cannot believe that using the code in wget as an example of the documentation could violate anything. Perhaps I am just too naive. Aaron www.cs.bham.ac.uk/~axs
there's already code in mozilla to parse server-sent dates (date: and last-modified:; at least cache needs this).
(In reply to comment #39) > there's already code in mozilla to parse server-sent dates (date: and > last-modified:; at least cache needs this). > So you mean that there is hope that this can be done in the future?
*** Bug 345457 has been marked as a duplicate of this bug. ***
I am surprised how many duplicates have been filed (including my own) without any further development and for how many years this issue has remained unsolved. I think it is a considerable design flaw that this information of interest is being neglected by download. Therefore I do not even consider it an enhancement request but rather a major bug; I tried to raise the severity accordingly but have no rights to do so, original reporter, please try that if you don't mind. Summarising the discussion: * Date/Time of last modification is significant information for certain file management tasks. This is especially true for downloaded files, but would also be good for saved HTML pages. * It can be easily retrieved from an HTTP header and there is no need for a discussion about algorithms or licensing of other software. * File systems maintain multiple date stamps; the original modification stamp would be set to the modified date of the downloaded file, the download time would implicitly be the creation date of the downloaded file. This is the standard Unix behaviour (where creation date cannot be manipulated anyway) and feasible on other systems too. It enables all users to retrieve the information they want. Please don't deprive us of this information any longer!
anyone with the proper rights please change product/component/version/severity etc. ?
Everything is correct (based on previous comments and current status of bug)...
In reply to comment #45 > anyone with the proper rights please change product/component/version/severity there was comment #46 > Everything is correct (based on previous comments and current status of bug)... I do not consider "enhancement" to be proper/correct for this long-term annoyance. Why is there no mechanism to raise severity (and maybe gain some more attention) to bugs? Voting could be enhanced with an importance assessment, for example. Opening a new bug as a remedy isn't appreciated either, as https://bugzilla.mozilla.org/show_bug.cgi?id=345457#c4 shows. User xtc4uall wrote in https://bugzilla.mozilla.org/show_bug.cgi?id=382597 > i wish this could be done under CON-004a of the PRD > (http://wiki.mozilla.org/Firefox3/Product_Requirements_Document#P2_2) This is an interesting document. If one of the mozilla members recently contributing to this bug (Dave Townsend / Shawn Wilsher) and who probably has editing rights there, would like to add this issue to the requirements, it would be highly appreciated.
This is a fact of life in a community project with voluntary effort. You cannot force others to take on an issue because you yourself consider it important... The only thing you can do is solve the issue yourself and try to get your patch incorporated in the release. However, even that can be difficult.
(In reply to comment #48) Yes, I know all this, but: * it's not just myself considering this to be important but quite a number of people, being evident by the large number of comments and duplicates * why does this bugzilla not allow to adapt severity? * by what means would I be granted authorization to contribute to mozilla requirements (as quoted in #47)?
See Bug 390776 (Add a bunch of other properties to nsIDOMFile) It is adding feature for web sites to read last modified datetime from local/network drive. So having this feature in download will allow websites (especially MS-Sharepoint, Alfresco, google docs, and webmail sites) to maintain last modified time of files during collaboration.
Similar bug on mail/news Bug 277405 – Support Content-Disposition's create/modified date fields
This bug exists in 3.0b5
As far as I'm concerned, downloading is equivalent to copying a file from point A to point B, and just like copying a file from a folder somewhere to your desktop doesn't change the date, downloading a file from a website somewhere to your desktop should also not change the date. File systems and files have creation dates and modified dates and they should be used properly and respected. Moreover with the date embedded right there in every HTTP request header, this isn't asking too much. This should have been fixed long ago and it has garnished a lot of attention and continues to do so. As more web applications are developed and demonstrate how files are copied around and shared, this will become more annoying. It seems only WGET has got this right.
(In reply to comment #12) > If we make this an option, we better not have UI for it. 99% of people could > not care less about the timestamps on the files. > > I'm not particularly inclined to make it an option in any case. We should just > pick one or the other and do it. Seems to me that anyone who thinks like this should never contribute to a general purpose very powerful software package (like Firefox) to be used by millions of people all round the world from many cultures with many different requirements. It's OK to take that attitude for some in-house package where users can be expected to conform to local conventions. It's just great arrogance to take that attitude to the rest of the world. It's arguable that some options should be in an 'advanced' part of the preferences UI, and this could be one of them. My hunch is that there are many people who would prefer this option if given the choice but do not realise that such a feature is even a possibility. But that's just a hunch. In the past I have seen many "naive" users acquire new motivations by being exposed to options they would not have thought of. One reason this has become urgent for me is that increasingly I find I am interacting with sites that will not allow me to use 'wget' because the relevant URLs are hidden so that only 'save as' in a browser can be used. I don't know whether in the cases where the URL is hidden the last modification date is available for Firefox to use when the file is downloaded. I fear not. Also, some sites are password protected, making use of wget messy, compared with using FF's stored passwords. As usual I am very grateful to all the developers, and apologise for not being able to contribute other than by testing new versions. (Currently 3.0.1) I agree with the comment in 47 that there should be a mechanism for voting for change of status of a bug -- I see this as a bug not an enhancement request (just as a copy file facility without the option to preserve date when copying has a bug). I also appreciate the problems of depending on voluntary workers.
I have started complaining to websites that do file sharing in hopes they will go to the browsers and ask them to add the feature. Many of these are Microsoft so if I go to http://skydrive.live.com/ complain to them and ask them to go to IE and fix this problem someday perhaps IE will get a clue and so perhaps Mozilla will get a clue. My hope is rather than the lowly user, if major website B or sister company can contact someone resonable they will get things done. I think I'm insane. There are numerous different file sharing sites that I have made a complait to. Meanwhile since I don't actually use Mozilla to download I suggested an update to the pretty addon: "download status bar" and I am now actually resorting to the addon: "downloadthemall!" which has the option -- Yippy! Those people who use WGET like me can use downloadthemall! (stupid name). But actually, and despite whatever, I'll probably still use WGET as much as I can, just because I use it by default.
(In reply to comment #53) > As far as I'm concerned, downloading is equivalent to > copying a file from point A to point B, and just like > copying a file from a folder somewhere to your > desktop doesn't change the date, downloading a file from > a website somewhere to your desktop should also not change the date. So what about uploading file? Whether it takes local file timestamp to the web server?
(In reply to comment #54) > One reason this has become urgent for me is that increasingly I find I am > interacting with sites that will not allow me to use 'wget' because the > relevant URLs are hidden so that only 'save as' in a browser can be used. > > I don't know whether in the cases where the URL is hidden the last modification > date is available for Firefox to use when the file is downloaded. I fear not. The URL is hidden only from the user, not from Firefox. Firefox needs the URL to download the file. Consequently, the last modification date is still available as long as the Web server sends the Last-Modified HTTP response header. You can probably find the URL if you read the source of the download page. Then you can feed the URL to wget, but you may need to set the Referer (sic) request header to the URL of the download page. You may also need to make wget use Firefox's User-Agent string instead of reporting itself as wget. This is necessary because some Web servers may deny requests from wget in an attempt to discourage recursive leeching (mirroring). I say "in an attempt to discourage" instead of "to prevent" because mirroring is often still possible by telling wget to report itself as a Web browser, ignore robots.txt, send a Referer, and delay for a random period of at least n seconds between requests. The delay can even be long enough to simulate a human reading the served pages and deciding which link to follow instead of a program parsing the served page. :)
(In reply to comment #55) > I have started complaining to websites that do file sharing in hopes they will > go to the browsers and ask them to add the feature. > > Many of these are Microsoft so if I go to http://skydrive.live.com/ complain to > them and ask them to go to IE and fix this problem someday perhaps IE will get > a clue and so perhaps Mozilla will get a clue. My hope is rather than the > lowly user, if major website B or sister company can contact someone resonable > they will get things done. > > I think I'm insane. You are *not* insane: I agree with you. Or perhaps we are both insane. ;)
Flags: wanted1.9.2?
Months ago, I checked out the Mozilla tree in order to try fixing this bug myself. I gave up because it would have taken weeks to understand the Mozilla internals. Furthermore, most of my experience is with C, not C++. Anyway, I have finally done something effective/productive because this bug continues to bother me: I have used oDesk.com to hire Michał Ściubidło to fix bug 269728 in Thunderbird. After Michał has fixed bug 269728, I will hire him to fix this bug! Consequently, please assign this bug to me.
Attached patch Proposed patch for trunk (obsolete) — — Splinter Review
Save original timestamp on file downloads. It works for http, ftp and file protocol. Parsing in nsFTPChannel could be moved to nsWebBrowserPersist and nsExternalHelperAppService if it would be better. Code that read modification time is identical in nsWebBrowserPersist and nsExternalHelperAppService. Maybe it should be moved to one function but i don't know where to put it.
Attachment #390269 - Flags: review?(file-handling)
Comment on attachment 390269 [details] [diff] [review] Proposed patch for trunk Thanks a lot for the patch! Not sure who the best reviewer here is, but let's try bsmedberg.
Attachment #390269 - Flags: review?(file-handling) → review?(benjamin)
Assignee: file-handling → michal.sciubidlo
Keywords: helpwanted
Comment on attachment 390269 [details] [diff] [review] Proposed patch for trunk I'm not sure this is a good change, but I'm also pretty sure I'm not the person to make that decision. Punting to bz who can maybe punt it to somebody else...
Attachment #390269 - Flags: review?(benjamin) → review?(bzbarsky)
QA Contact: ian → file-handling
Whiteboard: p-safari
Thinking about this more, I don't think it's a good idea. I expect the last-modified time on files to reflect the last time they were modified on my computer, not the last time they were modified somewhere else...
(In reply to comment #63) The files you use Mozilla to download from the Web were not modified on your computer. They were /copied/ to your computer. If you want to know when the files were copied to your computer, use the creation time or status change time (ctime) field in your file system. When I copy a file, I expect its last modified time to be preserved. cp, copy, wget, rsync, lftp all support this. Mozilla does not. I should not have to copy the URL of a file I want to download from a page I am viewing in Mozilla and paste the URL in a terminal to use wget to download the file just to preserve the last modified time. Windows users do not even have wget unless they have manually installed it. All programs that copy files should support preserving the last modified time. Many Web browsers, including Mozilla, do not. I care about this issue enough that I hired Michal Sciubidlo to fix Mozilla. I think most non-technical end users do not care whether the last modified time of downloaded files is preserved. I think many such users do not even notice that Mozilla does not preserve the last modified time. Because I know there will always be users who do not want Mozilla to preserve the last modified time, I propose making Mozilla preserve the last modified time by default and adding a pref for users who do not want Mozilla to preserve the last modified time. The pref does not need a GUI: users who care about this issue should be sufficiently technical to know how to use about:config. The GNU coreutils version of cp already allows the user to choose whether he or she wants the last modified time of copied files preserved. However, the default is to /not/ preserve the last modified time; the -p option must be used to preserve the last modified time. I know this is the opposite of my proposal for Mozilla, but the audience of cp is significantly different than the audience of Mozilla. cp users need to know how to use a Command-Line Interface (CLI) and need a terminal emulator installed. Mozilla users do not need to know how to use a CLI; many Mozilla users do not use a CLI. Netscape Navigator, Netscape Communicator, and early versions of the Mozilla Application Suite supported platforms such as Mac OS Classic that did not even have a CLI unless a development environment such as the Macintosh Programmer’s Workshop (MPW) was installed. Mozilla is used on some computers running Mac OS X that do not even have the Terminal application installed. I have met Mac OS X users in person who use Mozilla but have never even used Terminal. I discovered this because I noticed the shell (bash) had no command history saved when I used Terminal. Of course, when I say Mozilla, I include Firefox, because this bug affects all Mozilla-based Web browsers. This bug’s reporter was using the Mozilla Application Suite (Mozilla v1.2b), not Firefox, which was called Phoenix at the time.
(In reply to comment #63) > Thinking about this more, I don't think it's a good idea. I expect the > last-modified time on files to reflect the last time they were modified on my > computer, not the last time they were modified somewhere else... Comment #64 From Brolin Empey answers most of this as do previous comments in the discussion. I merely want to add that it is quite wrong for individuals to offer 'I don't want to do X' as a reason for making it *impossible* for others to do X. If there are people who want both options both options should be available in any powerful tool used world-wide by people from many cultures, with many levels of technical skill, with many different job requirements, different personal needs etc. If firefox is not supposed to have that universality, and is merely supposed to reflect the personal preferences of a subset of developers and users, then I want something else in its place. At present people who want dates of files changed to the download date have that provided. People who want the original time information preserved have no way to do that in Firefox. It should be available. Which one should be the default is another discussion. I think the default in Unix/Linux 'cp' is badly wrong. I have often found important historical information in a directory tree completely lost because someone who had no understanding of the issues just used the default recursive copy, and all files acquired the same date, which made it impossible to use a directory listing to find which ones had been most recently changed, etc. Defaults should preserve information that could be important rather than removing the information, especially as it is trivial to record the date of a download or copy. Sometimes people don't realise that they are being deprived of a facility, because they did not know they had that facility. It does not mean they did not need that facility. They just survived without it -- tolerating the inconvenience. Another question is how people should be able to modify the default. Given that it is an issue that has revealed very strong feelings here, it is clear that it should be easy for *anyone* to change the default. That means it would be wrong to assume that only an expert would want to change it. So it should be in the options menu. If the option is very visible then the debate about what the default should be is not so important. If the mechanism for change is as obscure as using about:config then it seems to me that this is an option that is too important to be left hidden in that way. (I can cope with about:config, but what I can do, as an experienced user, is irrelevant.) The fact that most people never complain about a default does not mean that it is of no importance to them. If they had the chance to use a different default and learn about its benefits then they might come to understand the importance of what they had previously not had. I have seen that happen many times during the development of computing in the last few decades. How many people knew they wanted tabbed browsing before they were presented with the opportunity?
> I think the default in Unix/Linux 'cp' is badly wrong. I have often found important historical information in a directory tree completely lost because someone who had no understanding of the issues just used the default recursive copy, and all files acquired the same date Totally agree. I run into this problem often, and am always having to badger coworkers to use -p. The Mac and Windows GUIs got this right. Given the design decision in Firefox to minimize the number of options visible in the preferences GUI, I think this is a good candidate for being an about:config option. I believe utilizing the Last-Modified header should absolutely be the default, and my guess is that there aren't enough people out there who would object to downloaded files' timestamps being preserved that it would have to be promoted to a GUI option. Brolin, thank you very much for hiring someone to fix this extremely annoying issue, and hopefully the work you paid for won't be thrown away because suddenly, 7 years after this bug was opened, one reviewer decides that timestamp preservation is a tool of the Devil. :-)
(In reply to comment #63) > Thinking about this more, I don't think it's a good idea. I expect the > last-modified time on files to reflect the last time they were modified on my > computer, not the last time they were modified somewhere else... Benjamin, would it make more sense to you if we were to store the file's timestamp from the server as the "Created" value and the download date/time as the "Modified" value? That makes more sense to me (and is actually what I thought the bug was going to do, but it'd been forever since I last read the whole bug).
> Benjamin, would it make more sense to you if we were to store the file's > timestamp from the server as the "Created" value and the download date/time as > the "Modified" value? That makes more sense to me (and is actually what I > thought the bug was going to do, but it'd been forever since I last read the > whole bug). Can you tell why it is better? Saving modification time as create time isn't intuitive for me. And there is another thing. When i edit downloaded file modification and access time changes. From now on I can't tell when the file was downloaded.
OK, so generally I'm in favor of doing this, I think. Michal, here are some specific issues with the patch that I'd like to see addressed before I start digging into the details: 1) nsIFile's lastModifiedTime is in milliseconds since the epoch. It looks like this patch relies on this being the case for the getter, but passes microseconds since the epoch to the setter and changes the Unix and OSX (but not Windows?) setter implementations to assume microseconds. Please don't change the nsIFile implementations, and pass in milliseconds as the API says. 2) There's no need to use the LL_* macros. We no longer support platforms without a native 64-bit integral type. You can just do arithmetic directly on PRTime/PRInt64 as needed. 3) Instead of putting the same code in the helper app service and webbrowserpersist, I'd prefer it went into nsNetUtil.h and was just called from both those callsites.
(In reply to comment #64) > (In reply to comment #63) > The files you use Mozilla to download from the Web were not modified on your > computer. They were /copied/ to your computer. If you want to know when the > files were copied to your computer, use the creation time or status change time > (ctime) field in your file system. > > When I copy a file, I expect its last modified time to be preserved. cp, copy, > wget, rsync, lftp all support this. Mozilla does not. I should not have to > copy the URL of a file I want to download from a page I am viewing in Mozilla > and paste the URL in a terminal to use wget to download the file just to > preserve the last modified time. Windows users do not even have wget unless > they have manually installed it. > > All programs that copy files should support preserving the last modified time. > Many Web browsers, including Mozilla, do not. I care about this issue enough > that I hired Michal Sciubidlo to fix Mozilla. > > I think most non-technical end users do not care whether the last modified time > of downloaded files is preserved. I think many such users do not even notice > that Mozilla does not preserve the last modified time. Because I know there > will always be users who do not want Mozilla to preserve the last modified > time, I propose making Mozilla preserve the last modified time by default and > adding a pref for users who do not want Mozilla to preserve the last modified > time. The pref does not need a GUI: users who care about this issue should be > sufficiently technical to know how to use about:config. > > The GNU coreutils version of cp already allows the user to choose whether he or > she wants the last modified time of copied files preserved. However, the > default is to /not/ preserve the last modified time; the -p option must be > used to preserve the last modified time. I know this is the opposite of my > proposal for Mozilla, but the audience of cp is significantly different than > the audience of Mozilla. cp users need to know how to use a Command-Line > Interface (CLI) and need a terminal emulator installed. Mozilla users do not > need to know how to use a CLI; many Mozilla users do not use a CLI. Netscape > Navigator, Netscape Communicator, and early versions of the Mozilla Application > Suite supported platforms such as Mac OS Classic that did not even have a CLI > unless a development environment such as the Macintosh Programmer’s Workshop > (MPW) was installed. Mozilla is used on some computers running Mac OS X that > do not even have the Terminal application installed. I have met Mac OS X users > in person who use Mozilla but have never even used Terminal. I discovered this > because I noticed the shell (bash) had no command history saved when I used > Terminal. > > Of course, when I say Mozilla, I include Firefox, because this bug affects all > Mozilla-based Web browsers. This bug’s reporter was using the Mozilla > Application Suite (Mozilla v1.2b), not Firefox, which was called Phoenix at the > time. Totally agree!!!! (And the default for cp should be -p also, but that's another question.)
(In reply to comment #63) > I expect the last-modified time on files to reflect the last time > they were modified on my computer, No that is not how on dos/windows it works. > not the last time they were modified somewhere else... On windows it always it is the last time they were modified in the original system. This is also true even in FAT and ZIP, expect they dont preserve the TimeZone. And I assume on unix also this is true for TAR/UNTAR ZIP/UNZIP etc.
A point that I think has not yet been made in support of this bug, that I've only just remembered, is that information about files downloaded, including url and date is already kept in Firefox's downloads list (Tools-->Downloads). So, not only is it true that people who want to record download times can do so at the time of download (in my case it's usually the source that is more important to record, which I now do manually), users can retrospectively find when a file was downloaded by looking at the downloads list in Firefox. In contrast, Firefox gives users no option to record creation/modification date of the source file when downloading. This use of the downloads list would be more convenient if it were possible (a) to export the downloads list (e.g. as text or html or xml file) preferably ordered by date, source, or title, (b) to quickly delete unwanted portions of the downloads list, since it often (in my case) includes huge amounts of stuff I no longer need to refer to, e.g. delete everything on a given day, or given month, or everything before or after a given date, or everything checked or selected in the displayed portion of the list --- since deleting is currently a very slow and tedious process. (I have not checked whether this has already been proposed as a bugfix, but will do that later when I get time.)
The patch is working like a charm. Thank you very much!
> A point that I think has not yet been made in support of this bug We don't need points in support of this bug. There's a patch. It's been reviewed. It needs to be fixed to work correctly, and then re-reviewed. That doesn't involve people landing 5-6 advocacy e-mails per day in my inbox, does it?
Comment on attachment 390269 [details] [diff] [review] Proposed patch for trunk See comment 69.
Attachment #390269 - Flags: review?(bzbarsky) → review-
I will post fixed path. I found a "bug" and i want to find best solution for it. On windows xp with ntfs ff writes to file after modification time is set (nsDownloadManager.cpp in line 2234).
(In reply to comment #76) > I will post fixed path. You need to path your brain again to write “patch” instead of “path”. ;) > I found a "bug" and i want to find best solution for > it. On windows xp with ntfs ff writes to file after modification time is set > (nsDownloadManager.cpp in line 2234). Did you test with VFAT too?
Attached patch Proposed patch for trunk (obsolete) — — Splinter Review
This patch is much smaller. 1) nsIFile's lastModifiedTime is in milliseconds since the epoch. It looks like this patch relies on this being the case for the getter, but passes microseconds since the epoch to the setter and changes the Unix and OSX (but not Windows?) setter implementations to assume microseconds. Please don't change the nsIFile implementations, and pass in milliseconds as the API says. Done 2) There's no need to use the LL_* macros. We no longer support platforms without a native 64-bit integral type. You can just do arithmetic directly on PRTime/PRInt64 as needed. Done 3) Instead of putting the same code in the helper app service and webbrowserpersist, I'd prefer it went into nsNetUtil.h and was just called from both those callsites. Now there is no same code in any two places.
Attachment #390269 - Attachment is obsolete: true
Attachment #391402 - Flags: review?(bzbarsky)
Comment on attachment 391402 [details] [diff] [review] Proposed patch for trunk Download manager is Shawn. That said, you should use PR_USEC_PER_MSEC instead of 1000, no? For the ftp code, someone familiar with the ftp format (and the issues around timezones, etc involved there) should look. Maybe Doug? In any case, you need to rev the iid and you need to initialize the member to something sane, since it's not set in all cases.
Attachment #391402 - Flags: review?(sdwilsh)
Attachment #391402 - Flags: review?(doug.turner)
Attachment #391402 - Flags: review?(bzbarsky)
Could you supply a diff with more context (preferably eight lines) and function headers please? [hg diff -U8 -p]
Attached patch Proposed patch for trunk (obsolete) — — Splinter Review
Patch created with hg diff -U8 -p. Using PR_USEC_PER_MSEC instead of 1000. Initialization of mLastModifiedTime in ftp to 0 (0=do nothing) What does it mean "to rev the iid"?
Attachment #391402 - Attachment is obsolete: true
Attachment #391434 - Flags: review?(doug.turner)
Attachment #391402 - Flags: review?(sdwilsh)
Attachment #391402 - Flags: review?(doug.turner)
Generate a new iid for the interface (using uuidgen or equivalent) and change the uuid() part in the IDL to list that new iid. That needs to be done when an interface vtable changes...
Attached patch Proposed patch for trunk (obsolete) — — Splinter Review
Generated new iid for the nsIFTPChannel interface.
Attachment #391434 - Attachment is obsolete: true
Attachment #391538 - Flags: review?(doug.turner)
Attachment #391434 - Flags: review?(doug.turner)
Attachment #391538 - Flags: review?(sdwilsh)
Comment on attachment 391538 [details] [diff] [review] Proposed patch for trunk This will need an xpcshell unit test for the download manager changes in order to land. Your bracing style for if statements is also very odd in nsDownloadManager.cpp compared to the rest of the file. if (cond) { } else { } is the proper form. Also, please add your new code before the ifdef for windows, and not in the middle of it. Lastly, you should pull that code out into its own method. Something like GetLastModifiedTime(nsIRequest *aRequest)
Attachment #391538 - Flags: review?(sdwilsh) → review-
> Also, please add your new code before the ifdef for windows, and not in the > middle of it. I didn't put it before ifdef because it changes last modified time. I taken out of ifdef declarations and if condition. I need them on all systems. Of course i can change that. What it the Mozilla way? nsCOMPtr<nsIFileURL> fileURL = do_QueryInterface(mTarget); nsCOMPtr<nsIFile> file; nsAutoString path; if (fileURL ...) { //ifdef //endif //last modification time } I will post another patch after this. Now i don't know how to fix it.
I would prefer you to have the last modification time before the platform specific code.
Two comments: * If I understand comment #85 properly, the platform-specific code would change the modification time again for some obscure reason, so it would be necessary to have the new code after that. * Michal, does your patch also apply to saved HTML pages (see my comment #42).
(In reply to comment #85) > I didn't put it before ifdef because it changes last modified time. Er, wait - which code is changing the last modified time exactly?
(In reply to comment #87) I saved page using "save page as" option in right click menu and it preserved last mtime. (In reply to comment #88) After moving code to GetLastModifiedTime(nsIRequest *aRequest) it looks like this: PRInt64 timeLastModified = GetLastModifiedTime(mRequest); if (timeLastModified) { file->SetLastModifiedTime(timeLastModified/PR_USEC_PER_MSEC); } It is called after ifdef block. GetLastModifiedTime takes request, checks it type (ftp,http,file) and tries to extract last modified time from it. If it can't it returs 0. If result != 0 last modification time is changed. Maybe i should post updated patch?
Please post an updated patch so I can see what you are talking about more clearly.
Attached patch Proposed patch for trunk (obsolete) — — Splinter Review
Includes changes proposed in comment #84.
Attachment #391538 - Attachment is obsolete: true
Attachment #396146 - Flags: review?(sdwilsh)
Attachment #391538 - Flags: review?(doug.turner)
Comment on attachment 396146 [details] [diff] [review] Proposed patch for trunk For more context, please see http://reviews.visophyte.org/r/396146/ on file: netwerk/protocol/ftp/src/nsFTPChannel.h line 111 > virtual NS_IMETHODIMP GetLastModifiedTime(PRTime* lastModifiedTime) { > *lastModifiedTime = mLastModifiedTime; > return NS_OK; > } > > virtual NS_IMETHODIMP SetLastModifiedTime(PRTime lastModifiedTime) { NS_IMETHODIMP already has virtual in the macro (see nscore.h) on file: toolkit/components/downloads/src/nsDownloadManager.h line 22 > * Contributor(s): Please add yourself to this list. on file: toolkit/components/downloads/src/nsDownloadManager.h line 401 > /** > * Returns last modified time from request. > * If result = 0 then it couldn't find last modified time in request. > */ proper javadoc style comment here please (@return and @param comments) on file: toolkit/components/downloads/src/nsDownloadManager.h line 405 > PRInt64 GetLastModifiedTime(const nsCOMPtr<nsIRequest> aRequest); You really want NS_IMETHOD_(PRInt64) GetLazyModifiedTime(nsIRequest *aRequest); Additionally, it should return the time in ms, not µs. If it returns 0, that just means it could have been set at unix epoch, right? Howabout we return PR_Now() (in right units) if we can't get the right value). on file: toolkit/components/downloads/src/nsDownloadManager.cpp line 22 > * Contributor(s): Please add yourself to this list. on file: toolkit/components/downloads/src/nsDownloadManager.cpp line 2252 > PRInt64 timeLastModified = GetLastModifiedTime(mRequest); > if (timeLastModified) { > file->SetLastModifiedTime(timeLastModified/PR_USEC_PER_MSEC); //expects time in miliseconds > } Just call SetLastModifiedTime(GetLastModifiedTime(mRequest)) with the previously mentioned changes. Also add a comment saying that the WriteFile command will change the last modifies time, and this is why we are doing it afterward. The unit test should catch this, but adding a comment here will be helpful for people in the future. on file: toolkit/components/downloads/src/nsDownloadManager.cpp line 3082 > PRInt64 NS_IMETHODIMP_(PRInt64) on file: toolkit/components/downloads/src/nsDownloadManager.cpp line 3083 > nsDownload::GetLastModifiedTime(const nsCOMPtr<nsIRequest> aRequest) I would prefer early returns for each case (nsIHttpChannel, nsIFileChannel, nsIFTPChannel) on file: toolkit/components/downloads/src/nsDownloadManager.cpp line 3086 > if (aRequest) > { nit: bracing style doesn't match dominate file style: if (aRequest) { on file: toolkit/components/downloads/src/nsDownloadManager.cpp line 3093 > if (PR_ParseTimeString(PromiseFlatCString(refreshHeader).get(), PR_FALSE, &timeLastModified) != PR_SUCCESS) { This is hard to read - please have the function call on it's own line and store the result in a variable. Then check the variable for PR_SUCCESS in the if block please. on file: toolkit/components/downloads/src/nsDownloadManager.cpp line 3099 > nsCOMPtr<nsIFileChannel> fileChannel = do_QueryInterface(aRequest); What do we get a file channel from? on file: toolkit/components/downloads/test/unit/test_lastmodified_time_preservation.js line 21 > * Contributor(s): Please add yourself to this list. on file: toolkit/components/downloads/test/unit/test_lastmodified_time_preservation.js line 37 > /** > * Test downloads file with specified lasd-modification time and checks > * modification time saved in file metadata (bug 178506) > */ It looks like you are modifying an existing test here. Please use |hg cp| to copy the first first, and then make your modifications so it's clearer as to what you are changing.
Attachment #396146 - Flags: review?(sdwilsh) → review-
Attached patch proposed patch (obsolete) — — Splinter Review
Included changes proposed in Comment #92. In #92 GetLastModifiedTime and GetLazyModifiedTime are used for the same function - "Lazy" is used only once so i didn't change it. > It looks like you are modifying an existing test here. Please use |hg cp| to > copy I did hg rm -f test_file && rm test_file && hg cp source test_file && cp myMofiedTest test_file.
Attachment #396146 - Attachment is obsolete: true
Attachment #401955 - Flags: review?(sdwilsh)
Attachment #401955 - Flags: review?(sdwilsh) → review-
Comment on attachment 401955 [details] [diff] [review] proposed patch For more detailed context (and visual diff with comments), please see http://reviews.visophyte.org/r/401955/. on file: toolkit/components/downloads/src/nsDownloadManager.h line 402 > * @param aRequest request from with last modified time is extracted nit: @param aRequest The request... (use full sentences please with punctuation) on file: toolkit/components/downloads/src/nsDownloadManager.h line 403 > * @return last modified time from request (in miliseconds). > * If it couldn't find last modified time in request PR_Now() if returned (in miliseconds). this doesn't seem to make sense completely on file: toolkit/components/downloads/src/nsDownloadManager.cpp line 2252 > //done after WriteFile() witch changes last modification time nit: real sentence please (this means start with a capital letter; end with punctuation) on file: toolkit/components/downloads/src/nsDownloadManager.cpp line 2253 > file->SetLastModifiedTime(GetLastModifiedTime(mRequest)); not checking return value, so case it to void. on file: toolkit/components/downloads/src/nsDownloadManager.cpp line 3080 > PRInt64 > nsDownload::GetLastModifiedTime(const nsCOMPtr<nsIRequest> aRequest) please see (and address) previous comment on file: toolkit/components/downloads/src/nsDownloadManager.cpp line 3084 > if (aRequest) { early return if this isn't true. The whole method is gated on this condition. on file: toolkit/components/downloads/src/nsDownloadManager.cpp line 3090 > nsresult result = PR_ParseTimeString(PromiseFlatCString(refreshHeader).get(), PR_FALSE, &timeLastModified); this doesn't return an nsresult. I think you want PRStatus? on file: toolkit/components/downloads/src/nsDownloadManager.cpp line 3092 > return PR_Now()/PR_USEC_PER_MSEC; nit: space around / on file: toolkit/components/downloads/src/nsDownloadManager.cpp line 3094 > return timeLastModified/PR_USEC_PER_MSEC; nit: space around / on file: toolkit/components/downloads/src/nsDownloadManager.cpp line 3096 > else { no else after returns on file: toolkit/components/downloads/src/nsDownloadManager.cpp line 3106 > else { no else after return on file: toolkit/components/downloads/src/nsDownloadManager.cpp line 3111 > return PR_Now()/PR_USEC_PER_MSEC; nit: space around / on file: toolkit/components/downloads/src/nsDownloadManager.cpp line 3113 > return timeLastModified/PR_USEC_PER_MSEC; nit: space around / on file: toolkit/components/downloads/test/unit/test_lastmodified_time_preservation.js line 58 > resp.setHeader("Last-Modified", "Sun, 09 Sep 2001 01:46:40 GMT", false); // = 1000000000 seconds Please don't use a magic string here - pull it out into a constant. on file: toolkit/components/downloads/test/unit/test_lastmodified_time_preservation.js line 69 > do_check_eq(destFile.lastModifiedTime, 1000000000 * 1000); Please do not use a magic number here - pull it out into a constant.
Attached patch proposed patch (obsolete) — — Splinter Review
Included changes proposed in Comment #94.
Attachment #401955 - Attachment is obsolete: true
Attachment #403329 - Flags: review?(sdwilsh)
Comment on attachment 403329 [details] [diff] [review] proposed patch Most of my comments are asking you to address comments I've already given you. Please don't waste my time by ignoring them without even explaining why you choose not to. http://reviews.visophyte.org/r/403329/ on file: toolkit/components/downloads/src/nsDownloadManager.h line 401 > /** > * @param aRequest The request from with time of last modification is extracted. > * @return Last modification time of a file if successful. > * If it couldn't find last modification time PR_Now() is returned (in miliseconds). > */ please see my previous comment about proper formatting for this on file: toolkit/components/downloads/src/nsDownloadManager.cpp line 3080 > NS_IMETHODIMP_(PRInt64) > nsDownload::GetLastModifiedTime(const nsCOMPtr<nsIRequest> aRequest) You still haven't addressed my comment about this method: It should be taking an nsIRequest * and not a const nsCOMPtr<nsIRequest> on file: toolkit/components/downloads/src/nsDownloadManager.cpp line 3091 > httpChannel->GetResponseHeader(NS_LITERAL_CSTRING("Last-Modified"), refreshHeader); You didn't address my comment about casting to void since you are not checking the result. on file: toolkit/components/downloads/src/nsDownloadManager.cpp line 3105 > file->GetLastModifiedTime(&timeLastModified); You didn't address my comment about casting to void since you are not checking the result. on file: toolkit/components/downloads/src/nsDownloadManager.cpp line 3112 > ftpChannel->GetLastModifiedTime(&timeLastModified); You didn't address my comment about casting to void since you are not checking the result. on file: toolkit/components/downloads/src/nsDownloadManager.cpp line 3115 > else > return timeLastModified / PR_USEC_PER_MSEC; ditch the else - just return timeLastModified / PR_USEC_PER_MSEC at the end of the function.
Attachment #403329 - Flags: review?(sdwilsh) → review-
Does anyone know what happened to Michal Sciubidlo? He has stopped answering my e-mails. I have not heard from him since 2009-09-21. I could not find his phone number in the Polish phone directories I searched. If he has only a cell phone, his phone number is probably not even publicly listed. At least that is how it is in Canada, where I live; I assume it is the same in Poland? The only other possible means of contacting Michal I have is his Gadu-Gadu (GG) number, but I do not use GG; it does not seem worth it to me to register for GG because GG is mostly used in Poland; I live in Canada.
I e-mailed Michal’s current employer to ask if they know what happened to him. No reply. I e-mailed his former university to ask the same. No reply. I do not even know if my messages were read because I am still using the Gmail Web interface, which does not support MDNs at all, for my personal e-mail. (fail) I know, I still need to buy a modern laptop so I can use Thunderbird instead of the Gmail Web interface for my personal e-mail so I can actually request MDNs when I send messages, but I am too ambivalent to choose a model of laptop. (fail) Anyway, is anyone willing to take responsibility for fixing this bug? I thought I should ask here before posting another job on oDesk.com to hire someone else to finish fixing this bug. I can even pay you if you want: I think I was paying Michal about 12 USD/hour. I know many people other than myself care about this bug, so please help me to finally get it fixed. At least I have a chance of getting it fixed because Mozilla is Free/Open-Source Software. Opera Software, despite claiming to deliver “Simply the best Internet experience”, is ignoring their users’s requests on their bulletin board to fix the same bug in Opera. There are users other than myself asking Opera Software to fix the bug too. Opera users do not even know if Opera Software has created an issue because Opera Software’s issue tracker is not publicly accessible because if it was, users could see how many bugs Opera Software is ignoring.
Attached patch proposed patch (obsolete) — — Splinter Review
This is updated patch from Michal Sciubidlo. It includes changes proposed in Comment #96. I'm not sure about proper formatting for doc because http://java.sun.com/j2se/javadoc/writingdoccomments/ shows a bit different rules for @param and @return content formatting Because some few people complained that they are happy with current behavior then patch also adds new preference "browser.download.manager.setLastModifiedTime". Default value is false. So you need to set this preference for saving last modification time from server.
Since only few people prefer the useless current behavior, why then should the default be false?
Andrey, did you mean to ask for reviews?
(In reply to comment #100) > Since only few people prefer the useless current behavior, why then should the > default be false? People usually complain about discomfort. So I think only a few people prefer to change behavior (compared to entire FF users) (In reply to comment #101) > Andrey, did you mean to ask for reviews? Brolin hired me for completing this bug. So, yes, please. Should I do something for that? Or ask Shawn directly?
If you make this a hidden config option, your valuable work will remain mostly useless... You should at least make it a clear option in Main/Downloads, next to "Always ask me where to save files"
A separate bug would be appropriate for addressing UI for the pref.
Andrey, you want to load https://bugzilla.mozilla.org/attachment.cgi?id=416320&action=edit and then change the "review" dropdown to "?" and type ":sdwilsh" in the textfield next to it. Then submit. I'd do it myself, but then I'd get the review-mail when Shawn reviews, not you...
Comment on attachment 416320 [details] [diff] [review] proposed patch Please review
Attachment #416320 - Flags: review?(sdwilsh)
Thank you Boris. I added review request to the patch
Flags: wanted1.9.2?
Attachment #416320 - Attachment is patch: true
Comment on attachment 416320 [details] [diff] [review] proposed patch For review comments inline, please see http://reviews.visophyte.org/r/416320/diff/. on file: browser/app/profile/firefox.js line 280 > pref("browser.download.manager.setLastModifiedTime", false); Per comment 69, we should just do this, and not have a preference. Please remove all code that deals with the preference (I won't comment on it further). on file: toolkit/components/downloads/src/nsDownloadManager.cpp line 2232 > You have added trailing whitespace here. Please remove it. on file: toolkit/components/downloads/src/nsDownloadManager.cpp line 2236 > You have added trailing whitespace here. Please remove it. on file: toolkit/components/downloads/src/nsDownloadManager.cpp line 2241 > // WriteFile() changes last modification time to current. > // Now file last modification time can be updated. > > // We need to check preferences if last modification time is really need > // to be updated. We aren't actually calling WriteFile in this code though, so this comment is a bit confusing. It's the call to SetFileAttributesWin that ends up calling WriteFile, correct? Also, the comments sound like broken English, and have funny wrapping (after a period, or 80 chars?). Just wrap at 80 characters please. on file: toolkit/components/downloads/src/nsDownloadManager.cpp line 3063 > if (!aRequest) > return PR_Now() / PR_USEC_PER_MSEC; The more I think about it, the more I think aRequest shouldn't ever be null. We should just change this to an assertion like so: NS_ASSERTION(aRequest, "Must not pass a NULL request in!"); Unless I'm wrong (which the tests will tell you), and then leave this in. on file: toolkit/components/downloads/src/nsDownloadManager.cpp line 3068 > // Trying to get typed request that support last modificaiton time This comment doesn't provide any value really (with modifications I'm going to suggest to your later comments). You can remove it. on file: toolkit/components/downloads/src/nsDownloadManager.cpp line 3070 > // HTTP may have Last-Modified header How about this: HTTP channels may have a Last-Modified header that we'll use to get the last modified time. on file: toolkit/components/downloads/src/nsDownloadManager.cpp line 3082 > // File has own LastModifiedTime attribute How about this: File channels have a lastModifiedTime attribute that we can get the last modified time from. on file: toolkit/components/downloads/src/nsDownloadManager.cpp line 3092 > // And ftp may return last modified time as well How about this: FTP channels have a lastModifiedTime attribute that we can get the last modified time from. on file: toolkit/components/downloads/src/nsDownloadManager.cpp line 3101 > // We do not know how to get modification time from other requests How about this: For this request, we do not know how to get the last modified time, so return the current time. on file: toolkit/components/downloads/test/unit/test_lastmodified_time_preservation.js line 18 > * Portions created by the Initial Developer are Copyright (C) 2007 nit: copyright date should be 2009 looking at the bug. This is super close. Probably be r+ next time I look.
Attachment #416320 - Flags: review?(sdwilsh) → review-
(In reply to comment #108) > (From update of attachment 416320 [details] [diff] [review]) > For review comments inline, please see > http://reviews.visophyte.org/r/416320/diff/. > > on file: browser/app/profile/firefox.js line 280 > > pref("browser.download.manager.setLastModifiedTime", false); > > Per comment 69, we should just do this, and not have a preference. Please > remove all code that deals with the preference (I won't comment on it > further). > FWIW, I absolutely depend on the current behavior and saving the original timestamp would be a regression for me. When downloading files, I'm only interested in when it was downloaded because recently downloaded files are more likely to be used than files downloaded long ago. (so sorting by last modified date is very useful)
(In reply to comment #109) > FWIW, I absolutely depend on the current behavior and saving the original > timestamp would be a regression for me. When downloading files, I'm only > interested in when it was downloaded because recently downloaded files are more > likely to be used than files downloaded long ago. (so sorting by last modified > date is very useful) This is the sort of use-case I had in mind when suggesting comment 67. If that were implemented, people who want to know when a file was originally created (or uploaded, depending on how the transfer method to the server handles dates) would be able to use the "creation date" field to be able to access the the "original timestamp" as requested here (and sort by that field, if desired), whereas those who only want to know when they downloaded the file would still be able to use date modified to figure out when they downloaded the file and sort by that field. Even better, for most users there would be no change whatsoever by preserving the "download date" on the last-modified; people who want to know the original timestamp (and I'm one of those) would just need to learn to look at the date created.
(In reply to comment #110) > If that were implemented, people who want to know when a file was originally > created (or uploaded, depending on how the transfer method to the server > handles dates) would be able to use the "creation date" field to be able to > access the the "original timestamp" as requested here (and sort by that field, > if desired), whereas those who only want to know when they downloaded the file > would still be able to use date modified to figure out when they downloaded the > file and sort by that field. I'd be supportive of this. bz - thoughts?
> I'd be supportive of this. bz - thoughts? It sounds fine to me, but I never care about any of the various timestamps associated with downloaded files so I might not be the right person to be asking... ;)
IMHO, Last Modified date should be the date in which the file was last modified. Creation Date should be the date when the file was created. Please, don't do it backwards!
If I want to see when exactly I downloaded some file, I should look at the Creation Date. If I want to see when was modified the file, I should look at the Last Modified date. The problem is that Firefox currently doesn't preserve the Last Modified date. Think, for example, when you transfer some file to a USB Flash drive and copy the file to another computer. You're doing something very similar to a download from an Internet server. Why the Modified Date is properly preserved when using Pendrives, but it's totally borked when downloading from the internet?!?!? Why are Internet users getting a flawed experience??
Comment 113 and comment 114 are correct, at least on Windows. If you copy a file from one Windows machine to another, the date modified is carried over from the original, and the date created is when the new file was created (i.e. when the copy occurred).
for parity reasons - just look at download manager software, which offers option to keep original timestamps - the original timestamp should be set in the local "modified field". IMHO every example of local file copy action, what points to a different behavior (e.g. comment 114, comment 115), is irrelevant alone for this reason.
(In reply to comment #116) > for parity reasons - just look at download manager software, which offers > option to keep original timestamps - the original timestamp should be set in > the local "modified field". > > IMHO every example of local file copy action, what points to a different > behavior (e.g. comment 114, comment 115), is irrelevant alone for this reason. Unless I'm missing something, you just agreed with comments 113-115. Newly created file (whether copied or downloaded): created date -> now modified date -> modified date of original
(In reply to comment #117) > (In reply to comment #116) > > for parity reasons - just look at download manager software, which offers > > option to keep original timestamps - the original timestamp should be set in > > the local "modified field". > > > > IMHO every example of local file copy action, what points to a different > > behavior (e.g. comment 114, comment 115), is irrelevant alone for this reason. > > Unless I'm missing something, you just agreed with comments 113-115. > > Newly created file (whether copied or downloaded): > created date -> now > modified date -> modified date of original Ron is correct: XtC4UaLL /did/ agree with comments 113-115. Comments 113-115 are correct: I know from personal experience. Comments 109-111 are illogical and wrong. Mozilla already records the date of downloads: see comment 72. sdwilsh: Do not ask apathetic people, such as bz, for advice! Do not accept advice from Smokey Ardisson because he (she?) apparently has not read comment 72.
Whiteboard: p-safari → [p-safari]
Target Milestone: Future → ---
(In reply to comment #110) > Even better, for most users there would be no change whatsoever by preserving > the "download date" on the last-modified; people who want to know the original > timestamp (and I'm one of those) would just need to learn to look at the date > created. Cross-platform considerations: Most unices don't save a creation date. They only have mtime (modification time), ctime (time of last status change -- i.e. chmod or chown), and atime (time of last access).
I have to agree with Shawn about removing preference from saving. So this patch will be applied faster. If too much people will complain about changed saved file order then preference may be added to the UI later.
Attached patch proposed patch (obsolete) — — Splinter Review
patch includes changed according to Shawn Wilsher review comments - removed preference - clean up comments - replaced aRequest NULL check with assertion in nsDownload::GetLastModifiedTime()
Attachment #416320 - Attachment is obsolete: true
Attachment #419099 - Flags: review?(sdwilsh)
Attachment #403329 - Attachment is obsolete: true
Comment on attachment 419099 [details] [diff] [review] proposed patch For review comments with more context, please see http://reviews.visophyte.org/r/419099/. on file: toolkit/components/downloads/src/nsDownloadManager.cpp line 93 > #define PREF_BDM_SETLASTMODIFIEDTIME "browser.download.manager.setLastModifiedTime" do not need this anymore on file: toolkit/components/downloads/src/nsDownloadManager.cpp line 2241 > // After all operations with file its last modification time needs to > // be updated from request nit: comma after |file|, before |its| on file: toolkit/components/downloads/src/nsDownloadManager.cpp line 3088 > if (NS_SUCCEEDED(ftpChannel->GetLastModifiedTime(&timeLastModified)) && > timeLastModified != 0) > return timeLastModified / PR_USEC_PER_MSEC; nit: brace this if please since the conditional is on more than one line. r=sdwilsh with these addressed.
Attachment #419099 - Flags: review?(sdwilsh) → review+
Attached patch proposed patch (obsolete) — — Splinter Review
fixed last comments
Attachment #419099 - Attachment is obsolete: true
Attachment #420582 - Flags: review?(sdwilsh)
Comment on attachment 420582 [details] [diff] [review] proposed patch >+ if (ftpChannel) { >+ if ((NS_SUCCEEDED(ftpChannel->GetLastModifiedTime(&timeLastModified))) && >+ (timeLastModified != 0)) >+ return timeLastModified / PR_USEC_PER_MSEC; I meant use { and } around the if statement, not add more parenthesis.
Attached patch proposed patch (obsolete) — — Splinter Review
added braces
Attachment #420582 - Attachment is obsolete: true
Attachment #420766 - Flags: review?(sdwilsh)
Attachment #420582 - Flags: review?(sdwilsh)
Attached patch proposed patch (obsolete) — — Splinter Review
sorry, I forgot about correct brace style
Attachment #420766 - Attachment is obsolete: true
Attachment #420774 - Flags: review?(sdwilsh)
Attachment #420766 - Flags: review?(sdwilsh)
Comment on attachment 420774 [details] [diff] [review] proposed patch r=sdwilsh
Attachment #420774 - Flags: review?(sdwilsh) → review+
http://hg.mozilla.org/mozilla-central/rev/8caf58f301b2
Status: NEW → RESOLVED
Closed: 16 years ago
Flags: in-testsuite+
Keywords: checkin-needed
Resolution: --- → FIXED
Summary: save original timestamp (last-modified date) on file downloads → save original last-modified date on file downloads
Target Milestone: --- → mozilla1.9.3a1
looks like this caused various failures in Ed tests, they are for sure firing: ###!!! ASSERTION: Must not pass a NULL request in!: 'aRequest', file /builds/moz2_slave/mozilla-central-linux-debug/build/toolkit/components/downloads/src/nsDownloadManager.cpp, line 3055 that comes from this patch. see http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1263113909.1263121538.6491.gz http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1263116117.1263122113.12715.gz TEST-UNEXPECTED-FAIL | /builds/slave/mozilla-central-macosx-debug-unittest-everythingelse/build/xpcshell/tests/test_dm/unit/test_bug_420230.js | test failed (with xpcshell return code: -6), see following log: TEST-UNEXPECTED-FAIL | /builds/slave/mozilla-central-macosx-debug-unittest-everythingelse/build/xpcshell/tests/test_dm/unit/test_privatebrowsing.js | test failed (with xpcshell return code: -6), see following log:
backed out
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Attached patch proposed patch (obsolete) — — Splinter Review
rolled back NULL check for aRequest in nsDownload::GetLastModifiedTime. nsDataChannel does not report any progress information to nsDownload, so aRequest remains uninitialized for such urls.
Attachment #420774 - Attachment is obsolete: true
Attachment #420980 - Flags: review?(sdwilsh)
Attached image access_time.png —
Not a Big Deal, ignore if it consume more time. 1. I have tested Jan 10 build which have this patch, on Win Vista downloaded "firefox-3.0.12-3.0.13.af.linux-i686.partial.mar" from http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/3.0.13-candidates/build1/ see attachment access_time.png, the Access Date is in 31-jul-2009 I feel it should have been 10-Jan-2010, as Win Vista will usually make Access Date same as Create Date when we copy a files, see in attachement the properties of "firefox-3.0.12-3.0.13.af.linux-i686.partial - Copy.mar" 2. on the patch ( attachment 420980 [details] [diff] [review] ) for FtpChannel we took effort to add a new method GetLastModifiedTime but for HttpChannel we did not not add GetLastModifiedTime method any specific reason???
(In reply to comment #133) 1. nsLocalFile::SetModDate updates last access time to the same value as lastModifiedTime. I'm not sure why. 2. There is no other way to get last modified time from ftp channel. And download manager code should query channel interfaces because nsIRequest is frozen and cannot be extended with property like lastModifiedTime. So better to reuse whole function in other places if needed.
Comment on attachment 420980 [details] [diff] [review] proposed patch >+NS_IMETHODIMP_(PRInt64) >+nsDownload::GetLastModifiedTime(nsIRequest *aRequest) >+{ >+ if (!aRequest) { >+ return PR_Now(); This is wrong. GetLastModifiedTime is supposed to return milliseconds, however: PR_Now() returns the current time as number of microseconds since the NSPR epoch, which is midnight (00:00:00) 1 January 1970 UTC. You want to divide by PR_USEC_PER_MSEC. nit: tab here, please use spaces.
Attachment #420980 - Flags: review?(sdwilsh) → review-
Attached patch proposed patch (obsolete) — — Splinter Review
fixed returned time for missed request
Attachment #420980 - Attachment is obsolete: true
Attachment #421228 - Flags: review?(sdwilsh)
Comment on attachment 421228 [details] [diff] [review] proposed patch r=sdwilsh
Attachment #421228 - Flags: review?(sdwilsh) → review+
The patch doesn't seem to apply cleanly anymore.
Keywords: checkin-needed
Attached patch proposed patch (obsolete) — — Splinter Review
synchronized with trunk
Attachment #421228 - Attachment is obsolete: true
Attachment #423819 - Flags: review?(sdwilsh)
Comment on attachment 423819 [details] [diff] [review] proposed patch I do not need to re-review this since all you did was rebase it on the latest trunk.
Attachment #423819 - Flags: review?(sdwilsh)
Attached patch proposed patch — — Splinter Review
updated patch to latest trunk changes
Attachment #423819 - Attachment is obsolete: true
(In reply to comment #142) > Created an attachment (id=424403) [details] > proposed patch > > updated patch to latest trunk changes Thanks, I'll get this landed this morning.
http://hg.mozilla.org/mozilla-central/rev/931dc23fa613
Status: REOPENED → RESOLVED
Closed: 16 years ago → 16 years ago
Resolution: --- → FIXED
Looks like the new test is failing on Windows: http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1264878571.1264880652.26782.gz s: win32-slave41 TEST-UNEXPECTED-FAIL | e:\builds\moz2_slave\mozilla-central-win32-debug-unittest-xpcshell\build\xpcshell\tests\test_dm\unit\test_lastmodified_time_preservation.js | test failed (with xpcshell return code: 0), see following log: TEST-UNEXPECTED-FAIL | e:/builds/moz2_slave/mozilla-central-win32-debug-unittest-xpcshell/build/xpcshell/tests/test_dm/unit/test_lastmodified_time_preservation.js | 1000003600000 == 1000000000000 - See following stack:
This is due to Bug 377307, I'm going to disable the test on windows
I really wish this had been put in with a pref (or some other way to disable it)... it represents a large change from the way browsers (certainly Moz stuff) have always worked, and completely breaks the widespread and expected usage pattern of always being able to see the latest downloaded files in a directory by sorting on "modified" times. Whatever happened to the "principle of least surprise" in UI-observable changes? Something this large really should have had much more visibility (and chance for debate) prior to checking in. Instead, the attitude adopted seems to be "just do it, and see if anyone squawks loudly"... sigh.
It's not a big deal under Windows, as NTFS gives you the file creation date. Just add the column in windows explorer (right click a column, and click "more") and you can easily sort the files. Most modern filesystems store the file creation date AND the file modification date. Please don't mix them up, they have different meanings. It's important to have both dates, they serve different purposes. Mozilla is going in the right direction here. This was a bug that needed to be solved. Regards.
(In reply to comment #147) > I really wish this had been put in with a pref (or some other way to disable > it)... > .... > Whatever happened to the "principle of least surprise" in UI-observable > changes? Something this large really should have had much more visibility > (and chance for debate) prior to checking in. I agree: it should have started as a preference. > Instead, the attitude adopted seems to be "just do it, and see if anyone > squawks loudly"... sigh. Even though I wanted the new facility, and want to make it my own default I agree that inflicting this sort of change on everyone without giving them a choice is usually bad software engineering. I have noticed strong resistance among FF developers to offering users options. (See comment #12) It seems to be based partly on the assumption that users can't cope with a large collection of preferences: but the ones who want them can -- if the options are well presented and well documented. (I think the vertical structure of preferences in Mozilla is far, far, better than the nested tab structure in Firefox.) We have to be grateful most of the time for people who contribute code -- and I am very grateful. But high programming ability doesn't always go with good understanding of human needs unfortunately. (I have worked closely with many excellent programmers.)
(In reply to comment #148) > It's not a big deal under Windows, as NTFS gives you the file creation date. > Just add the column in windows explorer (right click a column, and click > "more") and you can easily sort the files. > > Most modern filesystems store the file creation date AND the file modification > date. Please don't mix them up, they have different meanings. This is all true, and so what? Just because users have the ability to change their system configuration settings in a way many will not know about - to work around a change which is cool by some technical measure (but has been a bug that happily simmered since 2002 without loud demands to fix it) - does not make it the right thing to do. > It's important to have both dates, they serve different purposes. Mozilla is > going in the right direction here. This was a bug that needed to be solved. Maybe it is going in the right direction, maybe not... that wasn't the point. The point is a very observable change in something that has worked one way happily for what, 15 YEARS (or more, depending on how you measure it)? And then arbitrarily choosing to force the new behavior down everyone's throat with no warning, opportunity to disagree, or ability to optionally keep it working the way that users expect.
I've waited for that fix several years and so I'm glad now! > or ability to optionally keep it working the way that users expect. That is really a problem in firefox - user can (nearly) not customise it. No shortcut-configuration... That's why I don't like firefox too much. (An concerning e-mails kmail is a great alternative, but for browsers I still didn't find the best.)
(In reply to comment #150) > Maybe it is going in the right direction, maybe not... that wasn't the point. > The point is a very observable change in something that has worked one way > happily for what, 15 YEARS (or more, depending on how you measure it)? And > then arbitrarily choosing to force the new behavior down everyone's throat with > no warning, opportunity to disagree, or ability to optionally keep it working > the way that users expect. You cannot say that you were not given the opportunity to disagree, in fact you are doing it right now. I did not see a convincing argument as to why it would be optional, so I made a decision. Options aren't free, despite what people assert.
(In reply to comment #152) > I did not see a convincing argument as to why it would be optional The explorer on Windows by default displays "last modified" as column, but not "created". It's likely that users picked "last modified" to sort their download folder, and that some of these users are unable to cope now. That would have been an argument for making this new behavior opt-in or platform-dependent.
(In reply to comment #153) > The explorer on Windows by default displays "last modified" as column, but not > "created". It's likely that users picked "last modified" to sort their download > folder, and that some of these users are unable to cope now. That would have > been an argument for making this new behavior opt-in or platform-dependent. Sure, but it's just as trivial to add that column and sort by it in explorer as it would be to toggle and about:config preference. It also means we don't have to maintain more code logic + tests for it.
I wrote "opt-in", meaning that the new behavior wouldn't be enabled by default, exactly because I think requiring these users to toggle an about:config pref would be even worse than requiring them to customize the explorer.
When will this fix make it to a release? Hopefully, soon, in 3.6.x. In which case it would make sense for it to be opt-in, then in a more major release the default could be flipped.
This really doesn't fit the "security, stability, high-impact feature" bailiwick of 3.6.x. So no, it will not be landing there. For one thing, the patch that landed is not acceptable for 3.6.x (changes interfaces, etc).
No longer blocks: 545392
Depends on: 545392
Filed bug 545392 for adding a preference to switch between the last modified behaviors.
No longer depends on: 545392
Depends on: 545392
Depends on: 547606
(In reply to comment #153) > (In reply to comment #152) > > I did not see a convincing argument as to why it would be optional > > The explorer on Windows by default displays "last modified" as column, but not > "created". It's likely that users picked "last modified" to sort their download > folder, and that some of these users are unable to cope now. That would have > been an argument for making this new behavior opt-in or platform-dependent. I sort by date modified so that my text files I edit on a regular basis are at the end with the last pics and text files I have downloaded. If I sort by date created then these text files would be all over the place.
Steve, If you're using Windows, take a look at these freeware programs: http://www.gregorybraun.com/FMXTouch.html http://www.mkssoftware.com/docs/man1/touch.1.asp http://www.nirsoft.net/utils/filedatech.html They'll do what you want.
I agree with Michael Wu's Comment 109 and Robert Roessler's Comment 147. The patch writer was smart to include an about:config pref "browser.download.manager.setLastModifiedTime" that would optionally preserve the existing functionality - was it really necessary to remove this pref? Now that apples have been exchanged for oranges, the people who wanted oranges will be happy, but the people who were happy with apples will be upset. The correct way to fix this bug is to give the user a choice between the two options - neither of which is more "correct" than the other. There was a lesson to be learned from the awesome bar fiasco. A significant minority of people reacted negatively when, after a Firefox upgrade, the location bar started suggesting things from History and Bookmarks, with no option to turn these suggestions off. An option was eventually added on the Privacy tab of Tools -> Options. The turn-it-off option should have been introduced simultaneously with the "improvement," instead of much later. And then there was tab tearing - another feature to be introduced without an option (either in the UI or about:config) to turn it off, as if it was unfathomable that someone might find it more an annoyance than an improvement (due to accidental/unintentional tearing of tabs into new windows, which could not be reverted with Ctrl+Z); but, alas, the same mistakes are repeated over and over.
(In reply to comment #161) > Steve, > > If you're using Windows, take a look at these freeware programs: > > http://www.gregorybraun.com/FMXTouch.html > > http://www.mkssoftware.com/docs/man1/touch.1.asp > > http://www.nirsoft.net/utils/filedatech.html > > They'll do what you want. thanks for them, but I'll just stick with minefield 3.7preA1 as it acts like ALL the other browsers and for some strange reason is snappier than 3.7preA2. Brandon Mitchell you're RIGHT, it would be nice for it to be a selectable prefference seeing as EVERY other browser is now different to minefields saving date format. I can see thier point that it's ALWAYS been broke and that FTP clients act the same way as Minefield does now, BUT minefield is a BROWSER and NOT and FTP client.
I also agree that it should be a toggled preference. Especially seeing as this is fixing a so called bug going back from the VERY first build of firefox.
(In reply to comment #164) Marcus, this *is* a bug - and this is very strange that it is coming from the first builds of Firefox. I'm also afraid that this behaviour came from the Netscape codebase.
(In reply to comment #162) > Now that apples have been exchanged for oranges, > the people who wanted oranges will be happy, > but the people who were happy with apples will be upset. I am happy, but requested bug 549255 for you I feel we need same option while uploading a file (Bug 549253). As well as when we do email (Bug 549254).
(In reply to comment #162) > I agree with Michael Wu's Comment 109 and Robert Roessler's Comment 147. The > patch writer was smart to include an about:config pref > "browser.download.manager.setLastModifiedTime" that would optionally preserve > the existing functionality - was it really necessary to remove this pref? Unfortunately adding option required additional testing and code review effort from Shawn. So we decided to split things for simplicity. So we have additional bug for this part for simplicity
(In reply to comment #167) > Unfortunately adding option required additional testing and code review effort > from Shawn. So we decided to split things for simplicity. So we have additional > bug for this part for simplicity Where is that bug??
AFAIK, Minefield is currently the only GUI Web browser for Windows which preserves the Last-Modified time of downloaded files. I tested the latest releases of Safari, Chrome, Opera, and Windows Internet Explorer on Windows 7: they are all still broken. I am glad my preferred Web browser (Firefox) is no longer broken. :) Maybe now Apple, Google, Opera Software, and Microsoft will finally stop their apathy (stop ignoring their users’s requests) and fix their Web browsers? At least Windows Explorer already preserves the last modified times of files downloaded via FTP. Of course, it preserves the last modified times of files copied within local file systems and via SMB/CIFS, so why not via HTTP too?
This bug needs to be reassigned from Michal Sciubidlo to Andrey Ivanov.
(In reply to comment #169) > AFAIK, Minefield is currently the only GUI Web browser for Windows which > preserves the Last-Modified time of downloaded files. I tested the latest > releases of Safari, Chrome, Opera, and Windows Internet Explorer on Windows 7: > they are all still broken. I am glad my preferred Web browser (Firefox) is no > longer broken. :) Maybe now Apple, Google, Opera Software, and Microsoft will > finally stop their apathy (stop ignoring their users’s requests) and fix their > Web browsers? At least Windows Explorer already preserves the last modified > times of files downloaded via FTP. Of course, it preserves the last modified > times of files copied within local file systems and via SMB/CIFS, so why not > via HTTP too? Becuase thats not how things were EVER done via HTTP, thats what FTP clients are FOR. Hence why EVERY other browser still works CORRECTLY and Minefield is the ONLY broken web browser.
Also a web Browser is for the end user and thats why EVERY other browser acts the same and firefox is now the BROKEN browser and ALL the others are OK. An FTP client should preserve the date as it's mainly for the developer to upload/download files, so would need the date preserved. Thats's why there FTP clients AND HTTP web browser, an FTP clent doesn't show you the page/contents/pictures you're uploading and a web browser does.
marcusalden@live.co.uk: Thank you for answering my rhetorical question. ;) You are making a fool of yourself because you are so wrong. 1. Apparently you have never used wget nor read the earlier comments about it: wget correctly preserves the Last-Modified time of files downloaded via HTTP. 2. Apparently you never noticed Mozilla is an FTP client too. 3. Apparently you have never heard of a design concept employed by Mozilla called the Unity of Interface. 4. Do you seriously think the most common implementation is correct simply because it is the most common? (fail) Why do you think HTTP servers send a Last-Modified response header? So the client can ignore it? Do you think a DB9 connector is used for serial ports on PCs because DB9 is written more commonly than DE9? Serial ports on PCs use DB25 and DE9 connectors, but DB9 is commonly written, even though it is incorrect, because people do not understand the subject. Do you think the name IDE is correct and PATA is incorrect because IDE is popular with people who do not understand the subject? PATA and SATA are both IDE because they both have the controller electronics integrated with the drive. 5. Web browsers are used by developers too. 6. FTP clients are used by end users too. In fact, FTP is more popular with end users than developers because developers prefer better protocols such as sshfs and rsync. 7. Apparently you did not read the earlier comments which noted users who want to know when they downloaded a file can use Mozilla’s download manager and/or the Creation or Status Change (ctime) field of their file system. Sigh, why do I even bother getting involved in such futile arguments? (fail)
(In reply to comment #173) > marcusalden@live.co.uk: Thank you for answering my rhetorical question. ;) > > You are making a fool of yourself because you are so wrong. > > 1. Apparently you have never used wget nor read the earlier comments about it: > wget correctly preserves the Last-Modified time of files downloaded via HTTP. > No I haven't and neither has 98.5% of the other firefox users > 2. Apparently you never noticed Mozilla is an FTP client too. Yes it is but a VERY basic one and so are the OTHER browsers. > > 3. Apparently you have never heard of a design concept employed by Mozilla > called the Unity of Interface. NOPE > > 4. Do you seriously think the most common implementation is correct simply > because it is the most common? (fail) Why do you think HTTP servers send a > Last-Modified response header? So the client can ignore it? Do you think a > DB9 connector is used for serial ports on PCs because DB9 is written more > commonly than DE9? Serial ports on PCs use DB25 and DE9 connectors, but DB9 is > commonly written, even though it is incorrect, because people do not understand > the subject. Do you think the name IDE is correct and PATA is incorrect > because IDE is popular with people who do not understand the subject? PATA and > SATA are both IDE because they both have the controller electronics integrated > with the drive. > No but thats the way PEOPLE have got used to it. And thank you for enlightening my on PATA and IDE and SATA, what that has to do with the date that a browser saves it's files has is lost on ME. > 5. Web browsers are used by developers too. NOT to UPLOAD their websites though. > 6. FTP clients are used by end users too. In fact, FTP is more popular with > end users than developers because developers prefer better protocols such as > sshfs and rsync. > Yes they are but NOT to view the pages in HTML format > 7. Apparently you did not read the earlier comments which noted users who want > to know when they downloaded a file can use Mozilla’s download manager and/or > the Creation or Status Change (ctime) field of their file system. > But there are also comments to back my way of thinking. > Sigh, why do I even bother getting involved in such futile arguments? (fail) Yes, Maybe you are one of those people who has to have the LAST word. So now you can post another USELESS comment and have the LAST word.
This argument is very reminiscent of the old one about binary prefixes (gibibytes, mebibytes and all of that). Let's face it. In this world there are some people who always prefer the old way of doing things, even if that thing is broken. They don't want to change to new, better ways. Better the devil you know than the devil you don't, they say. People resist change because it's a hassle to modify your behaviour, even if the change is for the better. They will have to adapt and that costs them some time and effort. Eventually, they will get used to it and when they have successfully re-adapted to the new ways, they will start to feel comfortable and will quickly forget all the fuss they made about it in the beginning. So, Marcus, don't worry so much about it. You'll get used to it :)
(In reply to comment #174) > (In reply to comment #173) >> 1. Apparently you have never used wget nor read the earlier comments about it: >> wget correctly preserves the Last-Modified time of files downloaded via HTTP. > > No I haven't and neither has 98.5% of the other firefox users 98.5% - 1 (you) of the other Firefox users use whatever they have got. They have no idea what's right, what's possible and what they could look for.
With the current (new) way of time-tagging downloaded files, those who want the old way can do the following: 1. Copy the downloaded file, giving it a new name. (A new name is automatic with Windows). 2. Copy the name of the downloaded file. 3. Delete the downloaded file. 4. Paste the name of the downloaded file into the name area of the copy. This will give the file the current time-tag. With UNIX and likely with Linux, merely use the "touch" command on the downloaded file to give it the current date. With the old way of time-tagging, however, there was no way to set the time-tag to the original file's modification date without munging the system clock. In networked computers, such munging could be impossible. Thus, the new way of time-tagging increases the user's flexibility.
For people wanting the old behavior there is an extension https://addons.mozilla.org/en-US/firefox/addon/93121
Whiteboard: [p-safari] → [p-safari][use https://addons.mozilla.org/en-US/firefox/addon/93121 to get the old behavior]
Re comment 177: Where Windows preserves the original modification time-tag in a copy of a file, edit the first character of the file (using a hex editor if the file is binary), save the file, edit it again to restore the first character, and save it again. The new time-tagging for downloaded files follows the same convention as Windows does for file copies and UNIX does for the "cp -p" command.
From the Windows command-line reference <http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/copy.mspx>: * Changing the time and date of a file If you want to assign the current time and date to a file without modifying the file, use the following syntax: copy /b Source+,, The commas indicate the omission of the Destination parameter.
Fine, so this behaviour will be in the next Firefox (3.7) release? I'm happy.
Re-assigning as per comment #170 since it seems like Andrey fixed this one.
Assignee: michal.sciubidlo → andrey.v.ivanov
Please, someone summarize the final resolution of this bug.
(In reply to comment #183) > Please, someone summarize the final resolution of this bug. Next release will work correctly with last modification time value from the server. User will be able to rollback Firefox behavior back by using add-in from comment 178. Or it would be an build-in Firefox option if someone will fix bug #545392
(In reply to comment #184) Thanks Andrey. This is a long-awaited feature.
(In reply to comment #184) Hmm, sounds like the new timestamping mechanism would work correctly only with HTTP transfers, not FTP. Am I right?
Code uses MDTM response with code 213 and extract last modification time from this response. It ftp server response with other code then last modification time is not applied to the saved file
Removing [p-safari], since safari definitely doesn't do what this bug caused Firefox to do.
Whiteboard: [p-safari][use https://addons.mozilla.org/en-US/firefox/addon/93121 to get the old behavior] → [use https://addons.mozilla.org/en-US/firefox/addon/93121 to get the old behavior]
This hoses your file order in the downloads widget in the Mac OS X dock. Safari apparently used to do this and they changed it back to setting it to the download time. Every other browser in existence sets it to the download time. I think this is going to piss off a lot of users. (myself included, this hoses my workflow trying to locate things I just downloaded). I suspect those who want the server's timestamp are in the minority - the extension mentioned in the whiteboard ought to be to set the server timestamp, and default behavior should be the current time. Mainly because people expect things they just downloaded to sort to the top of their downloads folder, and people who actually care about preserving the modified time from the server will be savvy enough to go find the extension. People who want things to "just work" aren't even going to know the extension exists and will just go to some other browser that does it right.
You have "Creation time" to sort your files by download time. But if "Modification time" is set to download time too, there is no way to restore modification time from server. So if some application or user think that modification time is download time - it/she is wrong.
(In reply to comment #189) > Every other browser in existence sets it to the download time.... A timestamp change constitutes a file attribute change, regardless whether the file's content has changed. Real downloaders do not change any attributes of the files they fetch. I have no confidence that files with non-matching timestamps are the same even if name and size match. This is why with browsers prior to this fix I only download with wget and recommend others do the same, explaining that just because a web browser can fetch a file doesn't make it a downloader. > People who want things to "just > work" aren't even going to know the extension exists and will just go to some > other browser that does it right. "just work"/"does it right": 1-includes distinguishing files with identical names and sizes from each other. When the timestamp on the server matches the timestamp on the file I downloaded some time in the past, I deduce that they are the same file, and have no need to waste the time or bandwidth to download it again. 2-Those who want a current timestamp on a just downloaded file can easily change it to have one. Those whose just downloaded file has not preserved the original timestamp cannot easily restore it. I have to think most people usually sort downloads folders by name and not date, so most recent would not be listed at the top. OTOH, the browser's download window should know and show when it downloaded a file regardless what the file's timestamp is. Really, there ought to be a pref for this, and no extension needed regardless which behavior the user prefers.
Mac OS X sorts the download folder by modification date, by default. Most people don't know they can change the default. Firefox is meant to be for average end users, not for tech geeks (although tech geeks like the power that Firefox has to let them change things - hence extensions to make it work how the geeks want it).
(In reply to comment #191) > Really, there ought to be a pref for this, and no extension needed regardless > which behavior the user prefers. And yes, I agree. Bug bug 545392 got WONTFIXed... :(
In light of Firefox now being the only browser that does this, *and* this behavior completely breaking the download stack on OS X, this should be backed out. Also, now that I'm actually using Windows full time, I think I was wrong in comment 154. What I will support now is a patch to add the needed APIs to make an add-on that supports this behavior.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(In reply to comment #190) > You have "Creation time" to sort your files by download time. But if > "Modification time" is set to download time too, there is no way to restore > modification time from server. So if some application or user think that > modification time is download time - it/she is wrong. I am one of those who want to be able to have downloaded files retain their modification date from the server. I requested this five years ago. But I think making my preferred behaviour the default is very bad human interface design because the "wrong" default is what people have got used to. Unfortunately the response in comment #190 and the next one (comment #191) make a very common mistake among software developers, namely a failure to distinguish two questions about a feature in an existing package, namely: (a) how should the feature have been designed originally? (b) how should it be modified now that it has been in existence and widely used for a long time? The answer to (a) in this case is that originally (in all browsers) downloaded files should have been given their last modification dates from the server, for all the reasons that have been given. Unfortunately the answer to (b) is that since a large number of users have got used to a particular design and the developers have NO way of knowing how many users depend on that behaviour unless they do expensive surveys (individual intuitions about this are worthless, no matter how expert the individuals are as programmers: that does not make them good psychologists!) the existing behaviour should remain by default and the logical behaviour should be added as an option for the knowledgable users who want it. After that has been in existence for some time it would be reasonable to do a survey to find out what most users (especially non-expert users) would want the default to be. Unfortunately too many designers use their own intuitions about behaviours of others, or their views about what is right, to foist design decisions on large numbers of people. That is a very good way to alienate large numbers of people -- as is already shown by some of the reactions above. So can we keep the original (wrong!) default and provide a readily accessible option to switch between the two alternatives? I say that, even though I know that firefox keeps a download record that people can use to find recently downloaded files, in download order!
(In reply to comment #188) > Removing [p-safari], since safari definitely doesn't do what this bug caused > Firefox to do. What version of Safari are you using? Safari 5.0.1 still sets the file's creation and modification (and "Last Opened") times to the Last-Modified times from the server. It's infuriating, but it's still what Safari does. (I think Safari's behavior is bad, and the new Gecko behavior is just as bad; FWIW I still think my proposal in comment 67/comment 109-111 is a reasonable compromise, but the server-times folks didn't like it at all.)
(In reply to comment #195) > (In reply to comment #190) > Unfortunately the response in comment #190 and the next one (comment #191) make > a very common mistake among software developers Sorry, but if You think I think that behaviour should be changed unconditionaly, then it's wrong. At this moment I think that there SHOULD be configuration option in browser to save server modification time and it shuld be turned off by default, because many people think this is good behaviour. But any software that thinks this it is only possible behaviour should be changed.
(In reply to comment #197) > (In reply to comment #195) > > (In reply to comment #190) > > Unfortunately the response in comment #190 and the next one (comment #191) make > > a very common mistake among software developers > > Sorry, but if You think I think that behaviour should be changed > unconditionaly, then it's wrong. > > At this moment I think that there SHOULD be configuration option in browser to > save server modification time and it shuld be turned off by default, because > many people think this is good behaviour. Apologies, I misinterpreted the intention of your brief comment.
(In reply to comment #194) > What I will support now is a patch to add the needed APIs to > make an add-on that supports this behavior. That sounds more complicated and less likely to get done than an option, with the current release behavior being the default.
(In reply to comment #197) > (In reply to comment #195) > > (In reply to comment #190) > > Unfortunately the response in comment #190 and the next one (comment #191) make > > a very common mistake among software developers > > Sorry, but if You think I think that behavior should be changed > unconditionally, then it's wrong. > > At this moment I think that there SHOULD be configuration option in browser to > save server modification time and it should be turned off by default, because > many people think this is good behavior. > > But any software that thinks this it is only possible behavior should be > changed. I've been saying this since firefox broke this, and I use WINDOWS. Atte Kemppilä has made an addon to fix this https://addons.mozilla.org/en-US/firefox/addon/93121/ . So we know that over 1000 people that have found this have downloaded this. There are obviously more people that don't know this addon exists.
(In reply to comment #200) > There are obviously more people that don't know this addon exists. Because they has no need on it. I don't think that users of beta version could not find add-on that fixes some annoying feature.
(In reply to comment #201) > (In reply to comment #200) > > There are obviously more people that don't know this addon exists. > > Because they HAVE no need FOR it. I don't think that users of beta version could > not find AN add-on that fixes some annoying feature. I was just trying to help. if you didn't want the help you didn't have to say anything.
I am one of those who definitely prefer seeing the server time-stamp retained on the downloaded file. However, there are far too many users who really do not understand proper file management and configuration control and who want the download time to appear. Therefore, I support making the choice a preference. Neither side in this issue should have to resort to an add-on. Whether the default is to retain the server time-stamp or to use the download time would not be a serious issue if the preference could be set via a user interface in the Preferences window. By the way, if I want to determine if two files are identical, I hash-code them, using either MD5 or SHA1 depending on the sizes of the files. Yes, I know there are serious concerns about the use of MD5 and SHA1 for security; but they are still very useful for checking whether two files are indeed the same.
Attached patch backout v1.0 — — Splinter Review
This is the backout patch. I'm leaving the ftp channel stuff in so an add-on can still be made to do this. a=shaver over irc.
(In reply to comment #203) > By the way, if I want to determine if two files are identical, I hash-code > them, using either MD5 or SHA1 depending on the sizes of the files. Can you do that without downloading the 2nd beforehand? That's the comparison I usually want to make using the timestamp on the aleady saved file, to prevent needlessly downloading what I already have.
(In reply to comment #204) > > This is the backout patch. I'm leaving the ftp channel stuff in so an add-on > can still be made to do this. > The author of the patch added a preference (Comment 99), which everyone would have been happy with and which you told him to take out (Comment 108). Why are you backing out rather than putting back the pref?
(In reply to comment #206) > The author of the patch added a preference (Comment 99), which everyone would > have been happy with and which you told him to take out (Comment 108). Why are > you backing out rather than putting back the pref? I've stated why in this bug at least twice.
(In reply to comment #207) > (In reply to comment #206) > > The author of the patch added a preference (Comment 99), which everyone would > > have been happy with and which you told him to take out (Comment 108). Why are > > you backing out rather than putting back the pref? > I've stated why in this bug at least twice. Here's what you said in Comment 152: >I did not see a convincing argument as to why it would >be optional, so I made a decision. Now that you have seen a convincing argument, what's the problem? Is it still that it's too much work to make sure the option is working (Comment 167): >Unfortunately adding option required additional testing and code review effort >from Shawn. But that was when you didn't consider an option necessary, and now?
(In reply to comment #208) > Now that you have seen a convincing argument, what's the problem? Is it still > that it's too much work to make sure the option is working (Comment 167): Saying something is a convincing argument doesn't make it one to the person you are trying to convince. I don't see why this cannot exist as an add-on at this point. Adding additional preferences has a non-trivial cost, and the download manager already has lots of them. > But that was when you didn't consider an option necessary, and now? Still don't consider an option necessary, and the costs haven't gone away. I was originally fine with making this change because it seemed logical and did not break user experience. I was incorrect about the user experience (as noted in comment 194), and more information has come to light that makes the user experience on OS X terrible (comment 192).
Hello. I use "download time" method of sorting by years. After installing Firefox 4 I start loosing my downloaded files because I get used to sort them by Modification time. Now I have to use Firefox' option "Open folder" to find it.
(In reply to comment #209) > Saying something is a convincing argument doesn't make it one to the person you > are trying to convince. I don't see why this cannot exist as an add-on at this > point. The history of this bug should itself be convincing argument. Intelligent people differ on which behavior is appropriate. Each has managed to have its position implemented for some significant period. Neither can be convinced the other's position is correct. Therefore, built-in selectability is the right approach. > Adding additional preferences has a non-trivial cost, and the download > manager already has lots of them. "Download manager" will remain an oxymoron as long as the downloaded files cannot without an extension be identical in all respects to their sources.
(In reply to comment #209) > Saying something is a convincing argument doesn't make it one > to the person you are trying to convince. You admitted the option is needed when you decided to back out the changes for the sake of some. In general preserving the modified date during a transfer/copy is correct behavior. > I don't see why this cannot exist as an add-on Add-ons are for missing capabilities. Now that the patch has been incorporated, this capability is no longer missing, Fx can do it this way or that way, all that's missing is the means to specify the user preference. That clearly calls for an option and not an add-on. > Still don't consider an option necessary Ok, don't back out the changes then.
(In reply to comment #210) > Hello. > I use "download time" method of sorting by years. After installing Firefox 4 I > start loosing my downloaded files because I get used to sort them by > Modification time. Now I have to use Firefox' option "Open folder" to find it. Simple solution: sort your downloads directory by creation time instead of modification time. sdwilsh: Not preserving the last modified time of downloaded files already breaks the user experience because Windows Explorer, Finder, and common file browsers on *nix, such as Nautilus, Konqueror, and Dolphin unconditionally preserve the last modified time (when possible) of files copied locally or via a network, including via FTP. If Mozilla is meant to function like a native application, it should preserve the last modified time of downloaded files too. Backing out the bug fix patch, which has been incorrectly labelled as an enhancement by people who do not understand the issue, is silly because it appears to me to be caused by fear of change: Your argument appears to be “Mac OS X /currently/ sorts the downloads stack by modified time by default, so Mozilla cannot be the first Web browser to fix a bug which has existed since 1994 and probably earlier (in earlier Web browsers) because I cannot imagine Apple would even consider changing the download stack to sort by creation time by default if Mozilla was the first developer of a popular Web browser who actually fixed a 15-year-old bug instead of ignoring their users’s requirements and requests, as Opera Software (see my comment 98) and probably others, such as Microsoft, continue doing. New technology frequently faces a chicken-and-egg problem: people will not use it until it is widely supported, but it has to be widely used before it can become widely supported. PNG is a relatively recent example: some Web authors insisted on sticking with GIF and JPEG because some Web browsers which were commonly used at the time but were already outdated at the time, such as Netscape Navigator 4.x and IE6 for Windows, did not fully support PNG. Today, PNG is commonly used and all modern Web browsers are expected to support PNG. Animated GIFs are a similar and earlier example: they were not supported by early Web browsers (only the first frame was shown), but later entire industries, such as Web advertising, began relying on them being commonly supported. See comment 175. I would also like to note I care enough about this bug to have spent 588.30 USD of my own money to hire Michal Sciubidlo and Andrey Ivanov via oDesk.com to develop the patch which you are backing out because you appear to fear change. :( I would be interested to hear Tim Berners-Lee’s view on this issue. Tim developed the first GUI Web browser (WorldWideWeb, later renamed Nexus to avoid confusion.) on his NeXT workstation in 1990. Can anyone test WorldWideWeb/Nexus to see if it preserves the last modified time of downloaded files? Actually, now that I think about it, I do not know when the Last-Modified HTTP response header was introduced. In any case, I will try to ask Tim for his view. Will support from the creator of the Web be sufficient to convince the Mozilla organisation to make Mozilla preserve the last modified time of downloaded files by default in the next major final release (Firefox 4?)?
(In reply to comment #202) > (In reply to comment #201) > > (In reply to comment #200) > > > There are obviously more people that don't know this addon exists. > > > > Because they HAVE no need FOR it. I don't think that users of beta version could > > not find AN add-on that fixes some annoying feature. > > I was just trying to help. if you didn't want the help you didn't have to say > anything. Thank you very much and sorry for my bad english. There is the link to this add-on in this issue (comment 178). All I want to say is that there are more people that don't need this add-on at all. So I think that in this case "firefox change the default behaviour" is not equal to "firefox broke this". And I agree that adding the corresponding user preference is better than providing an add-on.
I'm sure the best way is to give users the oppotunity to choose what kind of timestamp to use.
To me it seems a bit overkill to have to download an add-on just for this. But I suppose I could cope with that (assuming that someone will be kind enough to develop such an add-on! ) I've noticed that almost every FTP client out there considers this issue important enough to have an user-visible preference for it. Please, please, please, at least make it a hidden preference in about:config. That would be better than nothing!
(In reply to comment #216) > To me it seems a bit overkill to have to download an add-on just for this. But > I suppose I could cope with that (assuming that someone will be kind enough to > develop such an add-on! ) > > I've noticed that almost every FTP client out there considers this issue > important enough to have an user-visible preference for it. > > Please, please, please, at least make it a hidden preference in about:config. > That would be better than nothing! This is what some of us have been asking for since firefox is the ONLY browser to fix this so called problem from 1992. But the addon by Atte Kemppilä is a god send, and if you don't want it or need it then don't download it it's really that simple. There are MANY more people that don't need this than do but that's the same for ALOT of firefox functions, if it was the case that only things that everybody wanted got changed then we would all be using IE4 or IE5 still, as IE is still ok for the masses.
I left the ftp changes in, like I said in comment 204, so making an add-on for this should be pretty trivial. The backout changeset is http://hg.mozilla.org/mozilla-central/rev/05028b7e5d6e In summary, I was originally OK with this because a group of people wanted it, and it didn't seem to really break the user experience for most people. However, I've realized I was incorrect (comment 194) for at least two platforms (the two most popular platforms we ship browsers on). Lastly, I don't support a preference because it has a non-trivial cost to maintain and support (during reviews and testing resources).
Status: REOPENED → RESOLVED
Closed: 16 years ago → 15 years ago
Resolution: --- → WONTFIX
(In reply to comment #218) > I was originally OK with this because a group of people wanted it, The reason to be ok with it that the the current behavior is manifestly wrong, a transfer is a copy and does not modify the file, therefore the modified date should be preserved > Lastly, I don't support a preference because it has a non-trivial > cost to maintain and support (during reviews and testing resources). That you can't be bothered to review and test it, does not sound like a legitimate reason for rejecting a patch that fixes clearly broken behavior.
Please note that the extension mentioned in the Whiteboard no longer does anything as it was meant to preserve the old behavior, which has now been restored. Either the extension needs to be updated (or a new one created) or we need a preference, or we will be stuck with the old, illogical, plainly broken behavior.
Not that this will have much impact now (I wish that I had brought it up when this first landed), but just for future reference: Very few Linux/Unix file systems actually support a creation date timestamp. Even though there are a few that do, much of the software stack doesn't support it either. http://en.wikipedia.org/wiki/Comparison_of_file_systems http://en.wikipedia.org/wiki/Ext4 (under Improved timestamps) So I'm glad to see that the original behavior was restored, and I'm glad to see the bits needed for extensions were left in.
(In reply to comment #218) > I left the ftp changes in, like I said in comment 204, so making an add-on for > this should be pretty trivial. The backout changeset is :sdwilsh, Will you be kind enough to create an Add-On for us? There are a big number people who want this big be fixed. Also will Brolin Empey get his money (588.30 USD) back? (In reply to comment #189) > This hoses your file order in the downloads widget in the Mac OS X dock. :justdave, Then that should be considered as a bug in Mac OS X. Can you tell me what happens to OS X dock when user copy some file from a network drive. That should also hoses your file order. I still feel the right way would have been by default preserve last modified time from webserver. And provide Add-on for users who want download time. I can grantee you will first see many downloads for the Add-on. But after few years people will start liking it, just like many users opposed Awesome Bar, and later start liking it.
All the contention and arguments in this bug report could have been avoided if there had not been a directive to remove the preference-driven option in the original implementation. Whose interests were served by that directive? Certainly not the users'. Note that resorting to the use of FTP is not always an option. I use FTP for downloads when I find a site supports it. But not all sites support FTP. And some sites are inconsistent; for example, Adobe's site supports FTP downloads for Adobe Reader but not for Flash.
In #218, Shawn wrote: > Lastly, I don't support a preference because it has a non-trivial cost to maintain and support (during reviews and testing resources). I don't believe you mean this to be an argument even against an about:config option as proposed in #216, considering its nearly 1000 entries anyway. About the Options dialog, I appreciate the original Firefox approach to keep it small and tidy. However, there are already more options than would be needed, and less useful ones than this would be, so even that's not quite convincing; e.g. right in the Downloads section, there is "Close it when all downloads are finished" - which could as well be just a checkbox in the Downloads window itself, thus making space for a new, much more useful option.
You know, it wasn't that hard to make. The important bits of code were already in the patches here. https://addons.mozilla.org/en-US/firefox/addon/222517/ (In reply to comment #222) > Also will Brolin Empey get his money (588.30 USD) back? Why should he? He privately hired a 3rd party developer to write a patch that was never guaranteed to be accepted. That was his risk.
(In reply to comment #225) > patch that was never guaranteed to be accepted. Maybe not, but it was implied by or via comment 33, comment 47, comment 123, comment 128 & comment 137. As long as timestamps cannot be preserved without extension(s), Gecko is modifying the files it fetches, no matter how trivially, and is thus not a competent downloader. Copying a file from a local source with copy, Explorer or cp -[a,p], or via rsync or other competent fetcher (e.g. wget, curl) from a non-local source does not unconditionally make such a change, and neither should anything claiming to be a downloader. Gecko should warn when asking to save a file that the saved file will be modified. Download manager should be renamed download corrupter unless this gets fixed. Note comment 10, comment 25
Could Mozilla put up a poll to see how many of the interested people prefer the old/current (broken in my opinion) behavior and how may would like to see this bug really fixed?
I think Matthew Turnbull made an excellent point in comment #221 when he pointed out that Linux/Unix file systems don't tend to support a file creation date. A horrendous oversight in designing those file systems in my opinion, but that's besides the point. I still think this should be fixed on Windows, and an about:config preference created for it, but I can see why it would cause problems on Linux and Mac OS to default to anything but the current behavior.
So is this being changed back? Because as a user used to sorting his downloads by date modified (which, for reference, utorrent also does), this is annoying the hell out of my in FF4beta4. What use is the original timestamp anyway? It's like replacing a feature with trivia.
File a bug with µTorrent about their wrong behavior then. And update to the latest beta, they already unfixed this bug.
(In reply to comment #230) > File a bug with µTorrent about their wrong behavior then. And update to the > latest beta, they already unfixed this bug. I think they have finally realised this was NOT a bug as it's on ALL browsers and on firefox from the 90's. They were trying to use the FTP escuse to justify changing this behaviour, but firefor is a web browser and NOT an FTP client. It may well do FTP but thats a secondary feature, I'm just glad they consided, and changed it back to the SAME behaviour as EVERY other browser in the last few beta's.
Yes, because if a lot of people do something, it's obviously correct. By the way, why are you using Firefox? Far more people still use Internet Explorer.
Can we please stop the discussion about the bike shed's colour already?
Yes, my apologies. I understand why the old behavior was restored, even on Windows. If its proponents could just agree that "I want this behavior because it's what I'm used to, logic be damned," I wouldn't mind so much. I just find it very aggravating that people keep trying to justify it with logical fallacies.
I gave a reason - it's more useful.
the BitTorrent protocol defines the "creation date" tag as an optional feature of torrent metadata files and many trackers don't use it. It's not even mentioned in the official specs: http://www.bittorrent.org/beps/bep_0003.html The "Last-Modified" tag in HTTP, however, is very clearly specified: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html And it's actually ENCOURAGED by the standard. It says that all HTTP servers SHOULD send that information to their clients. Firefox is ignoring that information, which is a very miserly behavior, in my opinion. Well, at least now we have an unofficial extension to fix this bug. It's better than nothing!
Internet Explorer and Safari use the Last-Modified HTTP header to set the file timestamp. Independent of whether the behavior of Firefox is deemed to be correct, there should be an option or an advanced setting in Firefox to control the behavior.
(In reply to comment #237) > Independent of whether the behavior of Firefox is deemed to be correct, there > should be an option or an advanced setting in Firefox to control the behavior. Shawn Wilsher has declared that the following code, implementing the option: PRBool setLastModifiedTime = PR_FALSE; if (pref) pref->GetBoolPref(PREF_BDM_SETLASTMODIFIEDTIME,&setLastModifiedTime); if (setLastModifiedTime) (void)file->SetLastModifiedTime(GetLastModifiedTime(mRequest)); as opposed to the unconditional: (void)file->SetLastModifiedTime(GetLastModifiedTime(mRequest)); is too burdensome for him to review and maintain. Isn't it obvious that's it's simply not worth the extra bloat and complexity? Who can tell what's lurking in that spaghetti code.
(In reply to comment #238) > is too burdensome for him to review and maintain. I see 31 vote for fixing this bug (ie, people who want sever LastModified time) And there is 40+ emails CCed before first landing patch on this (ie, 2010-01-10) And lot more duped afterward So I feel it worth the preference (In reply to comment #225) > You know, it wasn't that hard to make. The important bits of code were already > in the patches here. > > https://addons.mozilla.org/en-US/firefox/addon/222517/ I tested this in Win XP and Win Vista, it is not working on both... (add. info. I do have anti virus scanners on those systems, if that has any effect)
> (In reply to comment #225) > > https://addons.mozilla.org/en-US/firefox/addon/222517/ > > I tested this in Win XP and Win Vista, it is not working on both... > > (add. info. I do have anti virus scanners on those systems, > if that has any effect) Please download the latest version of the extension (better debugging output in the error console) and set browser.download.manager.scanWhenDone to false. See if that helps. I filed Bug 593553 on the issue.
The discussion is ennoying. Also a 10years old bug is a bug... What would be good for me - if as default or as configurable feature or as addon - I want a solution. If I understand right, the only solution for now is the addon https://addons.mozilla.org/en-US/firefox/addon/222517/ for firefox 4...pre ??? No solution for firefox 3? When will there be firefox 4 out? Or - where do I get firefox 4...pre? (Hope as tar-ball, not necessary to compile.) (using linux, opensuse) Thanks.
I just finished working on a new version of the addon to support Firefox 3.5+ and SeaMonkey 2.0. I still have some testing to do, and I need to sleep, so it will be up tomorrow (in about 10-15 hours).
Ok, the Firefox 3.5+ and SeaMonkey 2.0 compatible version was posted earlier today. If you're using the extension, and it works (Windows workaround aside), please rate/review it so I can get it moved out of the sandbox. For the sake of not spamming this bug, please direct all future discussion of the extension to it's support forum topic: http://forums.mozillazine.org/viewtopic.php?f=48&t=1984565
See Also: → 549253
Mozilla certainly has interesting development priorities: Firefox 4 can run Quake II without any plug-ins or extensions, but Firefox 4 still cannot even preserve the Last-Modified time of downloaded files without an extension! http://playwebgl.com/games/quake-2-webgl/ If you want to quickly try quake2-gwt-port for yourself, set webgl.enabled_for_all_sites to true in about:config, then open: http://tatari.se:8080/GwtQuake.html If the frame rate is too low, try making the Firefox window smaller. You may need to reload the quake2-gwt-port Web page after resizing the Firefox window. (In reply to comment #213) I e-mailed timbl on 2010-08-19 and requested an MDN, but never received an MDN or reply. I pinged timbl on 2010-08-29 but still never received an MDN or reply. I have considered calling him via Skype since it is long-distance, but am hesitant because I do not want to irritate him. I do not even know if he redd either of my e-mails, though. Maybe I should have included a Web bug in an HTML message, but then he still has to load remote content. Andrey Ivanov has agreed to (try to) fix bug 595785 so Matthew Turnbull’s extension can work correctly.
Update: please read http://forums.mozillazine.org/viewtopic.php?f=48&t=1984565&p=10608005#p10608005 . I know I could copy my message from phpBB and repost it here after reformatting it as plain text for Bugzilla, but I wanted to avoid unnecessary duplication.
(In reply to comment #244) > Mozilla certainly has interesting development priorities: Firefox 4 can run > Quake II without any plug-ins or extensions, but Firefox 4 still cannot even > preserve the Last-Modified time of downloaded files without an extension! Firefox ≥4 can now boot and run Linux v2.6.20 on an x86 computer emulated in ECMAScript: http://bellard.org/jslinux/ The current JS/Linux disk image even contains the BusyBox version of wget, but JS/Linux does not (yet) have network support (other than the loopback interface). The situation on the day when Firefox can preserve the Last-Modified time of downloaded files without an extension only by running wget on Linux in an emulated computer will be even more ironic than the situation today.
Absolutely unbelievable. I can't let this go without my two cents. Every other piece of file transfer software got this right, long BEFORE web browsers were even a twinkle in Tim Berners-Lee's eye. For example, one of the design goals of the YMODEM/ZMODEM protocols was to make preserving modification time possible, and this was circa 1985! Just look: http://gallium.inria.fr/~doligez/zmodem/ymodem.txt http://gallium.inria.fr/~doligez/zmodem/zmodem.txt "Omen Technology has trademarked the term True YMODEM(TM) to represent the complete YMODEM protocol described in this document, including pathname, length, and modification date transmitted in block 0. Please contact Omen Technology about certifying programs for True YMODEM(TM) compliance." Preserving modification dates was important enough to Omen Technology to create a certification program to ensure it is implemented! Just because web browsers have been getting it wrong for two decades doesn't make them right. Any argument based on "oh it's always done that" is ****. If you're going to try to argue seniority, web browsers are going to lose. Sorry kids, telecommunications did in fact exist before the web browser. I have been WAITING two decades for this to get fixed. Remember, back in the dark ages, Netscape was closed source. And now that we finally have the opportunity to fix it, "Oh sorry, our users (many of whom weren't even born when Netscape 1.1 was released) depend on us getting it wrong. Our hands are tied!" It breaks my heart. :( Unfortunately, "The majority of users expect it" *is* a legitimate argument. That still doesn't make it technically *correct* behavior. Let's please get that straight. Now pardon me while I go cry in my beer with my old buddy Atari ST and reminisce about the good old days when the majority of computer users were intelligent...
See bug #733954.
(In reply to Brolin Empey from comment #244) > (In reply to comment #213) > I e-mailed timbl on 2010-08-19 and requested an MDN, but never received an > MDN or reply. I pinged timbl on 2010-08-29 but still never received an MDN > or reply. I have considered calling him via Skype since it is > long-distance, but am hesitant because I do not want to irritate him. I do > not even know if he redd either of my e-mails, though. Maybe I should have > included a Web bug in an HTML message, but then he still has to load remote > content. http://lists.w3.org/Archives/Public/www-tag/2011Nov/0025.html Does anyone here, such as ninjaseg@gmail.com or David E. Ross, want to try convincing www-tag@w3.org to agree with my post and to act based on the requests I made in my post?
Product: Core → Core Graveyard
It was great fun to read this discussion. Personally, I think the file system time stamps are broken anyways: they change them rather arbitrarily, so they are utterly unreliable metadata. Generally, the browsers should have kept the original modification date from the server. However, they are setting it to the download time, and this behavior should not change, as no computer behavior should change without reason. Additionally, there should be no configuration option in Firefox, because every option is a bug. I write my own file server cgi, and I'm now considering to just send all downloads as .tar.zip archives. This has many advantages, but also solves the present time stamp issue.
Change of this behaviour has any good reason. Behaviour must change if it is broken, useless, or ill-designed in the first place. And while I agree that a large number of options is not good in general, this rule is violated by mozilla anyway, and for a good feature, there must be at least an option.
Add-ons that can preserve the modification timestamp, sent by the server, do not work in the new Firefox Quantum. Please, add this option to the main program.

Oops, the add-on is deleted and not available anymore. Well, these 6 lines of code in the core shown above would have lived longer. Maybe it was the wrong decision to move them out to a probably 500 lines long add-on that constantly has to battle ever-changing add-on APIs. Maybe it was also the wrong decision to let one person accept and then unaccept the patch only because he discovered the desired effects of it. Sad world. Firefox (and other "browsers") can't properly copy a file. I guess I'll have to solve this server-side for my app and package the downloaded file(s) into a ZIP archive only to preserve this simple information.

Or, as we can preserve the modification time of an UPLOAD with modern JavaScript APIs, maybe there should be a new JavaScript API to DOWNLOAD files in a decent way? Forget that ancient HTTP with its well-defined Last-Modified header, it's too buggy. We need a JavaScript way to push one or multiple files to the client, along with their correct name and modification timestamp.

I thought I should say that I mostly no longer use Firefox, for both desktop and Android, because I tired of the bad user experience, not because of this bug but because Firefox on Windows NT for x86-32 crashes too often for it to be usable and Firefox on Windows NT for x86-64 uses too many resources and becomes so unresponsive that I have to terminate it and start over. I switched to Vivaldi on desktop and Opera (the current version, based on Blink/Chromium) on Android until Vivaldi for Android is released. Firefox on Android OS 4.4 on my Samsung Galaxy Note 3 crashed so often that it was unusable. Now I have moved on from Android OS 4.4 on the Galaxy Note 3 to Android OS 8 on an LG G5 but I have not even tried Firefox for Android on the LG G5 because Opera for Android works well and I use a Web browser on my handheld computer only a little compared to other applications. I do not know if my bad user experience with Firefox on desktop platforms is because I still use Intel Core 2 era desktop computers in 2019 but why should I have to spend around 500 CAD times two to buy a current x86-64 desktop motherboard, socketed CPU, and RAM modules to upgrade or replace my desktop computer at both my home and office when my user experience with Vivaldi on my Core 2 era computers is still mostly satisfactory in 2019? If you want specifics, my home computer currently has an Intel Core 2 Quad Q9450 CPU and 16 GiB of main memory and my office computer currently has an Intel Core 2 Duo E8400 CPU and 8 GiB of main memory. Both computers use DDR2 SDRAM DIMMs for main memory, have the same model of fanless triple-head nVidia GeForce GT 730 PCI Express video card powered only by the slot/socket on the motherboard, and have three AMLCD video monitors with the same model of LG 3840×2160 4k UHD video monitor in the center. Both computers run Windows 10 Enterprise for x86-64 from a 2.5-inch SATA SSD, which may be 6 Gb/s (or Gib/s?) but the SATA host controller on the motherboard is only 3 Gb/s. Vivaldi being closed-source seems to not matter in practice. If I ever upgrade from a Core 2 era desktop computer, I ideally want a fanless computer with ECC NVRAM for main memory instead of a typical desktop computer with multiple fans and volatile main memory even if the main memory is ECC. “Web browser” is a very historical term in 2019 because by now a Web browser is its own computing platform that can run Quake III using OpenGL (WebGL) without any add-on and can run wget and similar programs on GNU+Linux running on an x86 computer emulated in JavaScript/ECMAScript. It is even possible to run a Web browser in a Web browser because a Web browser can emulate a computer running a network operating system that can run a Web browser. I also find it interesting that the first public Web site is back online at http://info.cern.ch/hypertext/WWW/TheProject.html .

I have to agree with @ninjaseg. In the meantime, here is a wonderful workaround:

  1. Install an older version of Firefox ( specifically, Firefox 52.9.0 ESR, not a version higher!)
  2. Install an older version of DownThemAll ( specifically, downthemall-nightly-20190820.xpi )
    https://code.downthemall.net/nightly/trunk
    https://code.downthemall.net/nightly/trunk/downthemall-nightly-20190625.xpi
  3. ENJOY the capability to download files with original timestamp.
  4. Donate to the DownThemAll team for providing a solution.

ALSO:
5. Download Firefox v52.9.0 from
https://archive.mozilla.org/pub/firefox/releases/52.9.0esr/

  1. Make sure you adjust Firefox settings (specifically, turn OFF Firefox from updating itself).

CORRECTION for #2 :
2. The correct version of DownThemAll ... for Firefox v52.9 ... is v3.0.8 (or older).
https://code.downthemall.net/releases/
https://code.downthemall.net/releases/downthemall-3.0.7.xpi

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: