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

Status: VERIFIED FIXED

(Core :: Networking: File, defect)

Description

[Felix Miata]

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.

Comment 1

[Felix Miata]

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.

Comment 2

[Felix Miata]

I did more checking. My HPFS partitions are littered with directories named *_files.

Comment 3

[Mike Kaply [:mkaply]]

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.

Comment 4

[Felix Miata]

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.

Comment 5

[Felix Miata]

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.

Comment 6

[Felix Miata]

Keyword regression added based upon Netscape 4.x behavior.

Comment 7

[Felix Miata]

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.

Comment 8

[Mike Kaply [:mkaply]]

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.

Comment 9

[Felix Miata]

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.

Comment 10

[Mike Kaply [:mkaply]]

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

[timeless]

we have a 4xp keyword for ..., regression is for things that once 
worked in mozilla 

Comment 12

[Mike Kaply [:mkaply]]

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

Comment 13

[Mike Kaply [:mkaply]]

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.

Comment 14

[Felix Miata]

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.

Comment 15

[Mike Kaply [:mkaply]]

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.

Comment 16

[Felix Miata]

You're welcome.

Verified fixed.