2002030716 OS/2 Mozilla asks for filename but doesn't save as chosen file on FAT16B partition. Neither "Save Page As..." nor "Enter name of file to save to..." dialog is followed by actual file writing. Reproducible: Always Steps to Reproduce: 1. Enable XFILE 2. Load any URL 3. Choose "Save this file to disk" and press "OK" 4. Choose any filename on a FAT16B partition 5. Press "OK" Actual Results: No file is saved. File saving dialog shows download complete, 100% progress. Choosing "show file location" from dialog presents a folder listing absent the name of the just "saved" file. Expected Results: File is saved.
Summary: Mozilla Doesn't Save File On FAT16B Partition → [OS/2]Mozilla Doesn't Save File On FAT16B Partition
Found a clue. On the HPFS partitions, the file save operation is creating a directory in the root called 0000_files. Since it can't do this on FAT16B, it quits without saving what it is supposed to be saving. The directory in each case contains a .css file and images.
I did more checking. My HPFS partitions are littered with directories named *_files.
This is a permanent restriction. When you save a page, Mozilla saves the contents of the page (note the text in the file dialog, Save Page Contents). It saves the page as www.place.com.html and the things needed to display that page in the directory www.place.com_files. This REQUIRES a long filename drive. The directory name must be longer than 8 characters, and most of the stuff on web pages that is downloaded (GIFs, JPGs, CSSs, etc.) requires long filenames. I'll add a readme item that basically says not to use FAT for anything Mozilla related. Honestly at this point, I can't believe there are still people that use FAT with OS/2. There might be a bug here that Mozilla doesn't report enough errors when it can't write files, but that would be a separate issue.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → WONTFIX
2002030816 This bug was filed as a consequence of confirming behavior for bug 70045. The menu item is "save page as", not something that implies anything more than a single file. In Netscape 4, this means saving the *the* page, not saving a page and all its elements. A page can be saved as 8.3 and thus should be able to be saved to FAT16B, particularly when all you are trying to save to begin with is pure text. Not only does it fail, it fails to save any portion of the selected page or its elements, even though some portion of the elements or the page itself conforms to 8.3 naming. This bug is not resolved.
Mozilla 0.9.8 for Linux has no problem saving a single 8.3 file to a FAT16B partition mounted as type msdos. The capability must already be there just waiting for OS/2 builds to hook into.
Status: RESOLVED → UNCONFIRMED
Resolution: WONTFIX → ---
Keyword regression added based upon Netscape 4.x behavior.
Keywords: qawanted → regression
From comment #3: "I can't believe there are still people that use FAT with OS/2." OS/2 is still used to multiboot DOS. OS/2 is still used to run DOS and Win3.1 apps. DOS and Win3.1 apps can only use 8.3 filenames. We save to disk for use by DOS and Win3.1 apps files they can use on drives they can see when necessary to boot DOS. Sometimes we do this because OS/2 won't boot in a reasonable time. I booted Linux to test a Mozilla bug and Linux went down with a little 2 Gb HPFS mounted. Now that drive is dirty and CHKDSK has been running since 17:30 EST and still isn't done. I have to boot DOS and do what needs doing that can be done. Good thing for Boot Manager. Trusty old DOS, but 8.3 required.
Os/2 currently has a bug that no matter what you select in the file dialog (entire page, HTML file, or TXT) it always does entire page, so this would fail on FAT16. Once the fix for 70045 is in, you will be able to select HTML or TXT and name it 8.3 and it will save to FAT. Entire page will not work on FAT.
Fix for bug 70045 (I filed) went in yesterday or today, right? I saw they could be related, but thought this and that separate issues. This and bug 70045 should both be fixed in today's PM build, right? Who cares about saving bunches of files (whole "page") to 8.3? All I wanted was what 4.x gave me.
The fix for 70045 only went into 0.9.9. It has not gone in to the trunk. Once it goes in, you will have what 4.x gave you. When you save a page, there are three options: Web page, complete Web page, HTML only Text file Web page complete will not work on FAT. It was not available in 4.x either. Web page, HTML only and Text file are what were availale in 4.x and they will work once 70045 is checked in.
we have a 4xp keyword for ..., regression is for things that once worked in mozilla
Keywords: regression → 4xp
QA Contact: benc → mrmazda
*** Bug 130277 has been marked as a duplicate of this bug. ***
Can you please try a nightly build and see if this works as you want now. This was NOT fixed in 0.9.9 I discovered. Saving Entire page does not work, but saving HTML and TXT to FAT works fine as long as the name is 8.3.
Assignee: dougt → mkaply
Worksforme in 2002031416. Maybe with a quirk. When "save page as" was first selected, Xfile came up with an empty "save file as type" field. The next time, the previous type selected was pre-selected.
I'm going to mark this as fixed. The other behavior you were seeing should have been fixed by a second checkin by me. I just verified that with XFile and the regular file dialog, when creating a new profile, it defaults correctly. Thanks for being patient with me in getting this one figured out. In the end it was just a big bug and I am glad it got fixed.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 16 years ago → 16 years ago
Resolution: --- → FIXED
You're welcome. Verified fixed.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.