Closed Bug 58733 Opened 25 years ago Closed 23 years ago

OS/2 - Preferences Should Not Require Long Filename Support

Categories

(SeaMonkey :: General, enhancement, P3)

Product:
SeaMonkey
Component:
General
Platform:
x86
OS/2
Type:
enhancement

Tracking

(Not tracked)

Status:
VERIFIED WONTFIX

People

(Reporter: barrymarshall, Assigned: mkaply)

Details

(Keywords: relnote)

According to http://bugzilla.mozilla.org/show_bug.cgi?id=55813 , Preferences requires long filename support (i.e. filenames greater than 8.3 characters). OS/2 4.x only has support for long filenames if you're using HPFS. With WSeB you can use either HPFS or JFS to get this. OS/2 out of the box does not include something akin to Microsoft's VFAT support to enable transparent long and short filename co-existance and acceptance on an 8.3 FAT file system. Trying to hack together something using the Workplace Shell to get around that problem isn't that good of an idea either. In some uses of OS/2 (automated banking machinery), FAT is the only recommended filesystem, so it means you can not use this product in that implementation. If this product is a true replacement for NS/2 4.61, we'd really need to get installability and the ability to run it on an 8.3 filesystem. What are the current limits of length and naming conventions on filenames supported by Mozilla? Don't some filesystems (some CD-ROM formats for example) have a maximum of 31 characters and only _'s? Maybe this is also of interest to the Embedded browser folks, since some of those systems use an embedded form of DOS to run those systems, don't they? This is a VERY low priority, since there's so much more to do that is more useful and requried for the world in general....
How important do you think is the ability to share preferences between OS/2 and other platforms? We could make things 8.3 for OS/2, but then we couldn't share preferences. We've looked at the 8.3 problem and have decided that this browser will not be supported on FAT, and will not be a replacement for 4.61 because of that.
This is valid and being worked
Status: UNCONFIRMED → NEW
Ever confirmed: true
HFS (the macos classic file system) was limited to 31 characters. FAT (So, windows3.1 is just as out of luck [except that no one is working on a port]) 8.3
I'm not sure I understand your notes. What does the ability to share preferences buy us? I mean, I understand it's easier to support a single set of code to generate, read, and process the preferences This is goodnesss, since there isn't as much stuff that's explicitly OS/2-related in the XP modules. How would not sharing Preferences change for this? I'm also not sure about your second comment. What's the current line of thinking? To create a seperate 8.3 version of Mozilla, or leave it as a Release Note?
As far as sharing preferences, Mozilla (and we) like the idea that I can take the users directory on Win32 and use it on OS/2. Or the user directory on BeOS and use it on OS/2. I can even store my prefefences on a server. If OS/2 added code that for OS/2 only used bookmark.htm and user-loc.rdf and others, then OS/2 preferences would not work on other platforms, and other platforms preferences would not work with us. There are other 8.3 implications as well, such as the components directory, messenger.jar, etc. Our current plan is to make it a release note. We are certainly going to pursue with Mozilla getting as many 8.3 things as possible or at least try to change the code to look for both long and short. That's actually a lot harder than it sounds.
Sounds good. Most installations I run would keep this type of data shielded from another OS, but I can see the transportability value. One other bit of nastiness would be installing new Chrome files. Since Mozilla opened up this to whatever you want, you also can't be guaranteed the actual execution data the user wants to run with is 8.3 compliant. Taking a quick breeze over bin\chrome\classic\skin\classic\communicator on my Win32 box shows many a non-8.3 name. Since you'd probably not want to try to have the program code modify the chrome files, you'd also have to have some way of mapping their entries to truncated filenames. Of couse, there's the basic question of how you'd get them out of the ZIP or distribution file in the first place... need some sort of Import program, I guess.
Actually, we shouldn't need to mess with those names at all. The jar file contains the long file names and never gets unzipped. So as long as the jar file is 8.3, we are OK. That's the beauty of the jars :)
That's what I thought they did... but then Win32 builds keep coming with all of these extra files and directories in them for some reasons. I just pulled 1101 and it still has them there. Any idea why? Is this used for performance reasons or have they not totally converted to JAR yet?
That's a feature. If you cause that to be removed I will be very upset. win32 is where many people develop packages / skins and do not build. since win9x does not have symlinks [nt5 does, but I don't build so just having symlinks isn't useful enough] and many people want to develop chrome w/o building you need an easy way to do the following: Make a change. See it live. Extracting the jars, altering them, and then repackaging them is a royal pain. For win32 non installer, you get them pre-extracted. which allows lots of useful things. I don't extract the entire archive, I just extract the changed chrome files (and don't use the jars at all).
'Nuf said. ;-)
Back on topic... When creating user profiles, the profiles are stored in a directory that matches the name of the profile. The problem with this approach is that OS/2 doesn't really let you use spaces in command line based sessions very well (if at all). If you have a directory called "Default User", it creates a directory called Default User. My stupidity may be showing here, but unlike NT or Win2K I can't just type "CD Default User" and have the command processor switch to it. This probbably also won't help matters if we are going to later enforce 8.3 compliance in the code. The directory is addressible through Workplace Shell and through other applications though, so it is a legal OS/2 directory name, albeit a bit of an inconvenient one. Is it possible to map of what characters are legal to use on the OS'es filesystems and how to convert them to a globally readable mechanism for other OS'es?
You can put it in quotes - cd "Default User" This bug will probably be marked invalid. We've pretty much resigned ourselves to the fact that we will be requiring long filenames.
Okay. It's probably more effort than it's worth, I guess. Adding relnote keyword in then... (unless someone's got a better keyword to use...) If that's the case, does the current milestone installer ensure that the code only gets installed on a long filename compatible filesystem? Does it put up a warning if someone tries to put it on 8.3 FAT? No one reads the documentation, so some sort of active enforcement is probably required.
Keywords: relnote
I'm not wild about FAT and 8.3 filenames, to be sure, but this problem may affect more than ATM machines and even local hard disks. Certain file servers (notably Novell NetWare without the OS/2 NLM, a common NetWare configuration) only support 8.3 filenames, and Mozilla would fail to function correctly in such environments. I found one possible workaround, although it's kludgy. Perhaps it's worth mentioning (though not endorsing) in the OS/2 README. You can create a RAM drive with long filename support using RAMFS, available here: http://home3.inet.tele.dk/kro/ramfs.htm Then you'd need a batch file like this: [Create the RAM Drive] [Unzip Mozilla.ZIP to the RAM Drive] [Run Mozilla] [Zip the RAM Drive back to hard disk] [Delete the RAM Drive] Bonus points if the critical user-updated files are sent to the Zip file periodically, if they're updated, by a background monitor. This would work on any FAT-only system with sufficient RAM. Another alternative is DCF/2, which is a container-based disk compression software package, but it's no longer being actively marketed by its vendor, DevTech (http://www.devtech.com). I believe DCF/2 containers support long file names. Still yet another option is the VFAT IFS for OS/2, provided the FAT drive is not the boot drive. But that's really cheating, since you might as well create a JFS, HPFS, or FAT32 partition while you're creating another drive letter.
We're not going to fix this. Mozilla requires long filenames.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → WONTFIX
Verify WONTFIX. If some big customer offers me A LOT of money, I'll do it :)
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.