based on Bug 70915 Downloaded file not moved from temp to final destination Test: I activated "Open File..." I changed Files type from "HTML" to "All" (this window should be resizable!) next I selected the file TEST.ZIP After pushing "Open" I hear the disk, i.e. the file is copied. On SYS$SCRATCH: is now a file: ZWDUZSP2.EXE;1 (what's the reason for changing ZIP to EXE ?) I checked the file it is identical to TEST.ZIP. In the appearing window "Downloading" is "Save to disk" already selected, I pushed "OK" In the window "Enter name of file to save to ..." I changed "Files of type" from "*.exe" to "All files". The file name is already given: test.zip. After selecting the path I pushed "Save". For a short time I see the window which shows the progress. ------- Additional Comments From Theo Jakobus 2001-06-13 07:28 ------- Mozilla version M0.9.1 does now move the file to the final destination, but it creates two versions, version *.*;1 with size 0 and version *.*;2 with the right file size. ------- Additional Comments From colin@theblakes.com 2001-06-13 07:39 ------- The extra empty version of the file is due to the way the Mozilla code is written. First they create the file (and close it), and then reopen it to actually write the contents. Because its opened with a truncate option, we get a new version created. An unfortunate side effect. There was a similar problem with another file (I forget which) and I believe this problem went away when the code was rewritten to eliminate the superfluous close/open. Maybe the same will happen in this instance. ------- Additional Comments From colin@theblakes.com 2001-06-14 02:52 ------- I guess we should have another bug for the file:// "extra close/open" issue. It results in the extra version of the file on OpenVMS, and is a (minor) performance issue on all platforms. The other place where this got fixed was the ftp:// download code, I believe. -yes, that sounds right. if anyone wants i can dig for the bug-

I think we just need to remove the PR_TRUNCATE from the line http://lxr.mozilla.org/seamonkey/source/xpcom/io/nsLocalFileUnix.cpp#656 The truncate is superfluous on all platforms (we've just created the file so by definition its empty and doesn't need truncating) and causes this "extra version" problem on OpenVMS.

I'm not convinced that PR_TRUNCATE isn't necessary. What if the file _does_ exist already? (I'm reading the code around here, but don't know enough about nsLocalFile to really be able to convince myself that that couldn't happen.) Get dougt and blizzard to tag team this one, I think.

We've just called NSLocalFile::Create. Doesn't that guarantee that we now have a brand new, empty file?

I've made a change to the OpenVMS porting library (which is used my Mozilla) so that when O_TRUNC is seen we open an existing file (if it exists) and truncate. This essentially mimics the UNIX behavior and makes this bug go away. I plan on including the fix in the M0.9.3 kit.

+verifyme - anyone want to take QA ownership?

Theo, would you be so kind as to verify that this bug is fixed. Thanks, Colin.

Testing under OpenVMS 7.3, DECwindow Motif 1.2-6, Mozilla Build ID 2001091217 Steps done: 1. Opened a zip file 2. Saved to another path ok 3. Opened the zip file again 4. Saved to path as in step 25. Message: "File exists, do you want to overwrite" YES 6. The file saved in step 2 is overwritten, which means it's replaced. All ok

Theo: if you do not have permissions to mark this "VERIFIED", I can do it for you.

I'm not the owner so I can't change the status to verified.

Marking verified.