[OS/2]Mozilla Doesn't Save File On FAT16B Partition

VERIFIED FIXED

Status

()

Core
Networking: File
VERIFIED FIXED
16 years ago
16 years ago

People

(Reporter: Felix Miata, Assigned: mkaply)

Tracking

Trunk
x86
OS/2
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

16 years ago
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.

Updated

16 years ago
Keywords: qawanted
Summary: Mozilla Doesn't Save File On FAT16B Partition → [OS/2]Mozilla Doesn't Save File On FAT16B Partition
(Reporter)

Comment 1

16 years ago
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.
(Reporter)

Comment 2

16 years ago
I did more checking. My HPFS partitions are littered with directories named *_files.
(Assignee)

Comment 3

16 years ago
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
(Reporter)

Comment 4

16 years ago
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.
(Reporter)

Comment 5

16 years ago
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 → ---
(Reporter)

Comment 6

16 years ago
Keyword regression added based upon Netscape 4.x behavior.
Keywords: qawanted → regression
(Reporter)

Comment 7

16 years ago
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.
(Assignee)

Comment 8

16 years ago
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.
(Reporter)

Comment 9

16 years ago
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.
(Assignee)

Comment 10

16 years ago
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.

Comment 11

16 years ago
we have a 4xp keyword for ..., regression is for things that once 
worked in mozilla 
Keywords: regression → 4xp
QA Contact: benc → mrmazda
(Assignee)

Comment 12

16 years ago
*** Bug 130277 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 13

16 years ago
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
(Reporter)

Comment 14

16 years ago
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.
(Assignee)

Comment 15

16 years ago
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 ago16 years ago
Resolution: --- → FIXED
(Reporter)

Comment 16

16 years ago
You're welcome.

Verified fixed.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.