When saving a file to a directory that doesn't exist, the directory is created automatically. This is different than 4.7, where save file fails with a "No such file or directory" alert. It's also potentially confusing for the user, since it's more likely that they've mistyped the directory name rather than intentionally wanting to save the file to a directory that doesn't exist yet. In that case, they won't be able to find the file they saved. To reprododuce: 1. File | Save Page As 2. Enter as path a nonexisting directory plus file name, say /home/user/test/test.html, where /home/user/test doesn't exist 3. Click OK Actual result: file saved, directory /home/user/test created. Expected result: "No such directory" error Linux build 2000.02.13.08

Reassigning as per Don

Move to M20 target milestone.

Oops. Should be M21.

this is a stale bug. it hasn't been touch in 30 days. i have tested it in the new netscape 2000080108 build and it does not it is not reperducable anymore so i sugges it be marked WFM.

Well, the error message is less than optimal, but it does fail with a warning now.

actually, this still happens for me. reopening. used linux comm opt 2000.08.28.11. here are my steps: 1. go to http://www.mozilla.org/ 2. scroll down to nightly build section, click on Macintosh link 3. click Save To Disk radio button in the Downloading dialog 4. click OK 5. in resulting filepicker, i typed in a bogus directory, eg, /u/sairuh/dkfsj/<filename_to_be_downloaded> 6. clicked OK result: the directory dkfsj was created and the file put there. there should be a dialog saying that there's no such directory, and asking if the user wants to create it. would this be a filepicker issue? cc'ing bryner and pavlov.

nav traige team: nsbeta3-

Yes, this is an issue with the XP filepicker. Currently is tries to save, then popups up a (for the user) useless error. I think we could fix this by checking if the parent of the file to save actually exists and is a directory and if not, we could pop up a dialog with something like "Directory you're trying to save in doesn't exist. [Create] [Cancel]" Suggestions?

Nominating; should be fixed as part of general cleanup of this area.

Netscape Nav triage team: this is a Netscape beta stopper.

*** Bug 64697 has been marked as a duplicate of this bug. ***

bill thinks pavlov shd get this. bill will talk to him about it :-).

I've put something provisional in around line 279 in filepicker.js, but I commented it out. I don't remember why, but if all you want is a simple warning, then commenting that out (and doing the i18n thing) should fix this bug. However, in bug 55026 it's been suggested we'd walk up the parents until we found which of them caused the problem (not existing/being a file/something else?) and report something more meaningful. Not too hard to do, imo.

nav triage team: Marking nsbeta1+

Taking bug, I'm sure Pavlov won't mind.

So for /tmp/foo/bar/baz/index.html, if /tmp/foo doesn't exist it will show an alert "Directory /tmp/foo doesn't exist, can't save /tmp/foo/bar/baz/index.html" if /tmp/foo is a file it will show an alert "/tmp/foo is a file, can't save /tmp/foo/bar/baz/index.html"

We have FormatStringFromName to do similar string construction and replacement. Not sure which is preferred.

cool patch. r=bryner.

what happens if there's both a file and a directory 'foo' in /tmp ? i know this bug is filed for pc/linux, but the file picker is xpfe.

Any filesystem which would allow that is broken by design.

Per Ben, common (universal) dialogs are preferred over simple alert()s to give more useful titles for error messages.

use formatstringfromname. %parent% is hard on localizers, partially because "%parent%" is an english string that does NOT get translated.

That much harder than %S? That would require a l10n note, which can equally well be provided for %parent%. Per conversation with Ben: <Ben_Goodger> I agree that %bar% and replace is better from js. I could change it to %P% and %F% if you feel English words are too confusing.

formatStringFromName is also cheaper to execute than string substituions in JavaScript, allows us to share the positional string formatting that we ALREADY USE from C++, and it uses the schema that translators have been using for years. Please. We have already decided that PR_smprintf (and thus formatStringFromName) is the i18n-blessed way of doing positional string formatting. please use it.

D'oh. Evil tabs. New fix coming up.

r=bryner

sr=alecf

Checked in, marking fixed.

cool. vrfy fixed on linux comm 2001.05.02.08 and winnt moz 2001.05.02.12. cannot vrfy on mac --filed bug 78581.