Selecting a zip file like HORRUM.ZIP opens the window "Downloading", selecting "Save to disk" opens the window "Enter name of file to save to...". In this window I select a directory, the file name is entered automatically. But the file is saved to SYS$SCRATCH: and the file name is changed from horrum.zip to 5YZC5I7G.ZIP. The file itself is ok.

reporter: could you tell us the url and your buildid ?

Build ID: Mozilla/5.0 (X11; U; OpenVMS 0 Digital_Personal_WorkStation_; en-US; 0.8) Gecko/20010214 This bug isn't url related. It's identical if I select a local file. I see the message: Document file:///iaf021$dka400/jakobus/horrum.zip loaded successfully JavaScript error: line 0: uncaught exception: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIHelperApp Launcher.setWebProgressListener]" nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "JS frame :: chrome://global/con tent/helperAppDldProgress.js :: onLoad :: line 317" data: no] After starting MOZILLA I always get the messages: $ mozilla Starting mozilla-bin... JavaScript error: chrome://global/content/scrollbarBindings.xml#scrollbar.initScrollbar() line 2: JavaScript error: line 0: uncaught exception: Scrollbars in this skin are not properly supporting mac smart-scrolling prefs!

The file is initially downloaded to /tmp (SYS$SCRATCH on OpenVMS) because the actual download starts BEFORE you enter the download file name. Once the download has completed the file is renamed (or copied, if necessary) to the user-specified name. So what you are seeing is the temporary file (which is given a temporary name such as 5YZC5I7G.ZIP) So, can you confirm that you are giving the download sufficient time to finish. Its not until the download is complete that the file is renamed/moved.

MOZILA 0.8.1 (Build ID: 2001032112) still has this bug. 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. But the file TEST.ZIP isn't copied to the selected path.

I can confirm this on i386 linux (release 0.8.1). The download completes successfully, but mozilla seems to be forgetting to copy the file. The temporary name seems to be generated randomly, if that helps.

Marking NEW.

-->law.

I'm updating the summary to remove the confusion about the temporary file. I seems that the problem is that the temporary file is not being moved to the destination when the download completes. There is no error handling in that code (a different bug, soon to be fixed) and it might be that the mv is failing because you don't have access to the destination directory, or the disk is full, etc. Could that be the cause of the problem? I'm particularly interested in whether or not the problem is specific top OpenVMS. There's one report of the problem on Linux, but I can't reproduce it there with a recent build. Tom, have you seen this problem in recent testing on Linux (or Mac or Win, for that matter)?

Updated to Mozilla 0.9 (Build ID: 2001050706) The bug is still around :( Answer to the comment given by Law: The final destination is part of my personal area, which is SYS$LOGIN under OpenVMS and I do have plenty of free space in quota and in real disk blocks. I waited minutes for a file with 110 blocks size. I'm curious if the bug is still in the next version I guess 0.91 ;)

It looks to be something peculiar to OpenVMS and we aren't likely to have fixed that. Somebody with a debug build on that platform might have to look into it.

Feel free to assign to me if you think this problem is now fixed on UNIX (I am the OpenVMS devo). Colin.

Done. Thanks for volunteering, Colin.

I found the problem. Its at http://lxr.mozilla.org/seamonkey/source/xpcom/io/nsLocalFileUnix.cpp#751 If the rename fails then we only resort to copying the file if errno=EXDEV. On OpenVMS errno is ENXIO if the source and target are on different volumes (akin to filesystems). Am I allowd to put an OpenVMS ifdef in there to check for ENXIO too?

Brendan, I believe you wrote the code at http://lxr.mozilla.org/seamonkey/source/xpcom/io/nsLocalFileUnix.cpp#751 This code is being a little too careful for OpenVMS. Its trying to rename a file, but when the rename fails it falls back to copy/delete. Only it will only try the copy/delete if the errno back from rename was EXDEV. This seems extremely cautious and in fact is too cautious on OpenVMS because there are situations where errno is ENXIO and a copy/delete would have worked. So, I need to make a change. I think the best plan is to always try copy/delete if rename fails. That way we stand the best possible chance of getting the file to the correct location if at all possible. What do you think? Can we remove the EXDEV check?

EXDEV is the only errno on unix-like systems that indicates copy/remove, which is non-atomic. Why does OpenVMS sometimes return ENXIO? What does it mean, and is it allowed by POSIX, e.g.? I can see falling back on copy/remove for other errors as we find specific exceptions, but if the error is EFAULT or EACCES, I see no point in trying to copy/remove. /be

> EXDEV is the only errno on unix-like systems that indicates copy/remove The only errno on UNIX systems. OpenVMS proves its not true for all unix-like systems :-) > Why does OpenVMS sometimes return ENXIO? What does it mean, and is it allowed by POSIX, e.g.? OpenVMS has a different file system to UNIX. There's no root and each device is treated as a separate entity. rename() on OpenVMS will only succeed on OpenVMS is both the source and the target are on the same physical device. From what I can tell, I think EXNIO generally means "invalid device", and would be returned if the source or target was specified as a non-existant device. But in this case the source and target can both be valid and ENXIO is returned meaning "invalid target device name for a rename operation". > I can see falling back on copy/remove for other errors as we find specific > exceptions, but if the error is EFAULT or EACCES, I see no point in trying > to copy/remove. I agree this is a very OpenVMS specific problem. But since this code is used by many UNIXes, some real and some pretend, I thought there was a chance that someone else might also return some non-EXDEV errno when a copy/delete might succeed. I was trying to fix those cases before we find them. Bottom line is I have to fix this somehow for OpenVMS. If a general solution isn't appropriate here I guess I need an ifdef for OpenVMS and check for ENXIO that way. Permission to insert a platform-specific ifdef?

Brendan?

Prevailing style does not overparenthesize == against ||, and does not put spaces on the inner surfaces of parentheses. Other than that, r/sr=brendan@mozilla.org. /be

Thanks Brendan. I'll check it in (without the superfluous parens and whitespace) as soon as the tree opens.

Checked in. Rev 1.46.

neither Tom nor I (the usual networking qa) can verify this.

Theo, can you verify this fix once M0.9.1 is released?

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.

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. Anyway, thanks for retesting.

collin: do you still have an open bug for that or would you like someone to file a new bug for it?

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.

ok I filed: bug 85939 "extra close/open" file:// issue: results in the extra file bug 85946 file picker isn't resizable on OpenVMS bug 85948 temporary filename extension shouldn't be EXE when we know t