Today's comm build Steps to Reproduce: (1) Go to ftp://ftp.gnome.org/pub/GNOME/unstable/sources/gtkhtml/ (2) Double click any of the .tar.gz files to download (3) When prompted, choose "Save to Disk" (4) In the filepicker, type in a non-existent path, e.g. S:\FOO Stack: MSVCRT.DLL + 0x127e6 (0x780127e6) nsLocalFile::Create [d:\builds\seamonkey\mozilla\xpcom\io\nsLocalFileWin.cpp, line 702] nsLocalFile::CopyMove [d:\builds\seamonkey\mozilla\xpcom\io\nsLocalFileWin.cpp, line 912]

There are two parts to this bug. The first part is the crash. It is caused by a bad assuption. I have fixed this crash in nsLocalFileWin.cpp. An error will propogate up from the localfile class when a move or copy, or for that matter a create happen and the file does not exist. The second part of this is having the file Save-As code deal with an error during the move from the downloaded "temp" file to the actually destination. This fix should be with law@netscape.com. I think. WIthout fixing this, a file downloaded to a non-existant drive will not complete nor alert the user that there is a problem. the dialog will never finish. I want this next patch to be checked in soon against this bug. After that I will reassign to someone on the apps team to fix the dialog. law, bbaetz, sairuh, can I get a r/sr on the next patch?

Comment on attachment 63847 [details] [diff] [review] protects against path without slashes sr=darin, but make the if (slash) block include the while (slash) block.

sounds good. one less check for null.

Comment on attachment 63847 [details] [diff] [review] protects against path without slashes r=gagan

crash fixed. Reassign to law. Bill, you need to handle the error if the destination can not be created. In the trunk build (as of now) the dialog hangs if you try to reproduce the bug.

Should we create a new bug for law's part, or transfer this to file handling?

All these download related items are moving out; delayed due to overhaul of downloading and many regressions in this area.

Spam: Setting target milestone for all these to Future. Please note that most, if not all, will be fixed in the course of the work I'm doing for bug 27609. That fact is noted in the "depends on" field for each of these bugs (I think; go ahead and remedy that if you like). I just don't have time to deal with the wrath that comes with having too many bugs.

> WIthout fixing this, a file > downloaded to a non-existant drive will not complete nor alert the user that > there is a problem. the dialog will never finish. Um...seems to me like the proper fix is to tell the user right away (i.e. have the filepicker throw an alert) that the path is non-existent. This is what Windows does generally...

Or give them the option to create it (assuming its the path which is missing, not the drive itsself, of course)

OK, I've added error-checking in some places, but probably not all. I think if the create fails when loading via the uriloader (exthandler), then it is caught. But if you're going via the webbrowserpersist, it isn't. I'll see about fixing the latter. There's also the issue of how good an error message the user gets (I think all errors are reported as NS_ERROR_FAILURE). I know sometimes the real reason is out-of-space (try saving to a completely full floppy disk). Then there's the problem of the file picker detecting this specific problem ahead of time. That's an nsFilePicker.js issue. Please open another bug on that.

dougt, bill: Is this ready to be marked RESOLVED?

I think so. There are still some residual difficulties dealing with errors that occur when copying/moving from the temporary file to the final destination, but there are bugs specific to that.

RESOLVED: WFM Win98, RC1. Bill has enough bugs that deal with other error handling conditions, so I'm closing off this bug now that the crasher is fixed.

bill: please VERIFY if you think this is taken care of.

+verifyme Blake: can you VERIFY this isn't crashing anymore?

VERIFIED/lxr: http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&file=nsLocalFileWin.cpp&branch=&root=/cvsroot&subdir=mozilla/xpcom/io&command=DIFF_FRAMESET&rev1=1.69&rev2=1.70