Closed Bug 547606 Opened 10 years ago Closed 9 years ago

Creation date is used instead of modified date, if file is saved after Firefox has completed download

Categories

(Toolkit :: Downloads API, defect)

x86
Windows XP
defect
Not set

Tracking

()

RESOLVED INVALID

People

(Reporter: fehe, Unassigned)

References

()

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a2pre) Gecko/20100221 BetterPrivacy-1.47 Minefield/3.7a2pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a2pre) Gecko/20100221 Minefield/3.7a2pre ID:20100221043554

If one does not click "Save" before Firefox has completed downloading a file, when "Save" is finally clicked, Firefox saves the file with modified time equal to creation time, instead of saving the file with original modified time.


Reproducible: Always

Steps to Reproduce:
1. Visit http://fileforum.betanews.com/detail/MediaInfo/1194575334/1

PART I: Saving with correct modified time

2. Click "Download Now" (on the right)
3. When the "Opening MediaInfo_GUI..." dialog appears, quickly complete the dialog so the file is being saved.  Make a note of how long it takes. 
4. Once the file has been saved, note the modified time is February 19, 2010, 10:38:24 AM

PART II: Saving with wrong modified time

5. Rename or delete the file from Step 4
6. Clear the cache via Tools --> Options... --> Advanced --> Network --> Clear Now
7. Refresh the page so that the "Opening MediaInfo_GUI..." dialog appears again.
8. DO NOT click to save the file.  WAIT a bit longer than it took to download the file in Step 3.
9. Once you are sure Firefox has completed downloading the file, click to save the file.
10. Now check the downloaded file's modified time.  Note that it is current and equal to the creation time, instead of the modified time in Step 4.
Blocks: 178506
Version: unspecified → Trunk
Summary: Creation date is used instead of modified date, if file is save after has completed download → Creation date is used instead of modified date, if file is saved after Firefox has completed download
Yep, just confirmed it with a somewhat bigger file (fast connection, heh). If the download finishes in the background before you select where and how to save it, last modified date gets messed up.
Me TOO, was trying to get this across in here http://forums.mozillazine.org/viewtopic.php?f=23&t=1763265&p=8762395#p8762395 but they didn't get it and said file a bug reporrt, but there was already one filled.
Component: File Handling → Download Manager
Product: Core → Toolkit
QA Contact: file-handling → download.manager
So is the file being cached to a temp folder before your actually saving it?  If so, I suppose you can imagine that it might be moving the cached file to the download folder and maybe the cached file is really created and modified (moved or copied) to your download folder at the time you hit save? 

(In reply to comment #2)
> Me TOO, was trying to get this across in here
> http://forums.mozillazine.org/viewtopic.php?f=23&t=1763265&p=8762395#p8762395
> but they didn't get it 

FWIW, Unfortunately this edge case wasn't clear enough to the people in the thread that it was really the problem being discussed.
(In reply to comment #3)
> So is the file being cached to a temp folder before your actually saving it? 
> If so, I suppose you can imagine that it might be moving the cached file to the
> download folder and maybe the cached file is really created and modified (moved
> or copied) to your download folder at the time you hit save? 

Not the case.  Until you save, the partial file is downloaded to your Windows TEMP folder.  It is moved to your chosen folder once you click to save.  You can use Sysinternals Process Monitor to verify this.

The way this bug works is: say you're downloading a 1 GB file and do not save until the file reaches 99 % complete, if you save before the last 1 % is complete, the original modified date/time is retained.  But if you save after the file has been 100 % downloaded to Windows TEMP, the original modified date/time is overwritten with the creation date/time.
@Dale.  I misread your post as saying it's saved to the cache folder.  So I basically said the same thing you said. :-)

But as you can see, there's no reason for making the distinction.  More likely it's just that this scenario got overlooked, for some reason.
Is Toolkit::Download Manager correct for this bug?  Bug 178506, which this is a remnant of, was Core::File Handling.
(In reply to comment #6)
> Is Toolkit::Download Manager correct for this bug?  Bug 178506, which this is a
> remnant of, was Core::File Handling.
It very likely is, but the two share a lot of the same code.
Status: UNCONFIRMED → NEW
Ever confirmed: true
(In reply to comment #2)
> Me TOO, was trying to get this across in here
> http://forums.mozillazine.org/viewtopic.php?f=23&t=1763265&p=8762395#p8762395
> but they didn't get it and said file a bug reporrt, but there was already one
> filled.

I believe what you're asking for is not the subject of this bug.  You're basically asking for pre-3.7 behavior, for which case someone has created an [experimental] extension available here: https://addons.mozilla.org/en-US/firefox/addon/93121

I have not used the extension and make no representations about its quality, so use at you own risk.
What is the likelihood of getting this fixed up for 2.0?
This bug is no longer valid since bug 178506 was marked WONTFIX.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.