Closed Bug 86538 Opened 24 years ago Closed 23 years ago

Unable to run / startup Mozilla CFM from a Macintosh UFS partition

Categories

(Core :: XPCOM, defect)

Product:
Core
Component:
XPCOM
Platform:
PowerPC
macOS
Type:
defect
Priority:
Not set
Severity:
minor

Tracking

()

Status:
VERIFIED WONTFIX
Milestone:
Future

People

(Reporter: slafredo, Assigned: ccarlen)

References

Details

(Keywords: relnote)

Attachments

(1 file)

a shot showing a path on a ufs volume
3.12 KB, image/png
Details
I installed Mozilla in my home directory. This is the same HD partition that contains the Mac OS X system. When I double-clicked Mozilla to run, I was saw... The loading dialog box. A blank page. A blank menu bar. I was able to... Use Cmd-N to create new windows. Use Cmd-Q to quit. Not able to use Cmd-W to close windows.
was this a carbon build, and does it work from an HFS or HFS+ partition?
URL: n/a
It was the 4/16/2001 CFM build and yes I installed it on a HFS+ partition and it ran fine.
:(
Assignee: asa → pinkerton
QA Contact: doronr → jrgm
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Target Milestone: --- → Future
*** Bug 86812 has been marked as a duplicate of this bug. ***
I also see this on the 7_03_01_branch build. (Newly installed OSX on UFS) the big white window can be re-sized (it has a grippy in the bottom right corner. unfortunatly it's too high up to grab the title bar. the only menus available are the apple menu and the "Mozilla" menu. Unlike the other reporter, I can't get cmd-N to open a new window.
Should this be nominated as an OSX Beta blocker? It leaves mozilla totally unusable on startup: It produces a big white window with no controls and no menus after the splash screen goes away.
Hmm After having tested both the 0.9.2 builds and the trunk builds, they both fail in different ways: Trunk build 2001070515 - Does the big white rectangle as described above. It works if I grab the viewer folder and drag it to a HFS+ pertition. 0.9.2 branch build 2001071205: The splash screen never goes away and startup never progresses beyond that. Option Q will will quit moz. It works if I grab the viewer folder and drag it to a HFS+ pertition.
we should certainly relnote this for beta, and try to fix for RTM. who should own this, and how do we go about getting this in the release notes?
Keywords: relnote
Whiteboard: OSX+
Ideally the installer should tell you that you can't install on UFS (when we have an X installer).
Release notes can be added to http://bugzilla.mozilla.org/show_bug.cgi?id=90577 for bugs that affect mozilla trunk and Netscape RTM.
*** Bug 94911 has been marked as a duplicate of this bug. ***
If you install Mozilla on an HFS+ partition, but your home directory is still UFS, some set of preferences do not get updated either. These include window size(s), and whether or not you see the sidebar. It's been a while since I've programmed MacOS, but are the Carbon APIs for the Resource Manager broken over UFS filesystems? Or are there newer Carbon APIs for the Resource Manager that Fizilla^H^H^H^H^H^H^HMozilla-CFM should be using?
*** Bug 97011 has been marked as a duplicate of this bug. ***
*** Bug 98968 has been marked as a duplicate of this bug. ***
Not that it wouldn't be nice to fix this but it isn't considered a stop ship - removing OSX+ status
Whiteboard: OSX+ → [OSX]
According to gramps he's not having any probs with his home directory being on an NFS volume accessed via NetInfo. He's looking for someone, in his words, "Stupid enough to have a UFS home volume" to test :-)
the 10.1 install docs strongly recommend that you don't format your volumes with UFS until you know for a fact you need it. Who knows for a fact they need it?
>Who knows for a fact they need it? Two basic reasons to use UFS: case sensitivity and repairability. For development having a UFS disk is useful for legacy unix stuff that uses case sensitivity to distinguish files, but enough breaks that it's not a good OSX homes disk. Unless you need to run a reliable server - fsck for HFS+ can't fix many HFS problems. If someone was running an OSX webserver it might be nice to have a copy of Mozilla locally for maintenance work. That's the only reason I can think of where it might be necessary, but you can work around it with a disposable HFS+ partition.
I might add I don't feel this is a Mozilla problem, as I'm using exclusively UFS on OS X v. 10.1, and have found other stuff is broken too (Toast comes to mind). Not sure whether this only relates to Carbonised apps, or Cocoa apps as well, but I guess to us it doesn't matter much. I suggest this be marked as an OS bug, and a bug report be sent to Apple telling them to fix their OS.
i am stupid enough to be running os x off of a ufs partition. i have lost one too many hfs/hfs+ partitions (and that last one was a doozy), plus, i wanted my every day os x environment to be entirely insulated from anything os 9 could do to it. right now i have simply worked around the problem by running mozilla off of a hfs+ os 9/os x partition, but i was forced to use ie for two days (ugh! horrible port of a naturaly bad app.), and omni web for three (hmm...not as bad, but still a bit clunky.) this needs to be release noted.
*** Bug 109243 has been marked as a duplicate of this bug. ***
as of mac os x 10.1.1 and build 2001112108 this is still a prevalent issue. in my case, i get a message that "mozilla unexpectedly crashed" while it's loading. never gets past the "starting up..." message. also, to answer something previously mentioned ... this is not just a cocoa v. carbon thing. many carbon apps work fine on my UFS partition. and while it would be cool if apple fixed this (assuming it is a bug on their side) other programs have gotten around this ... so why can't mozilla? (omniweb originally suffered from the same problem ... long ago.)
*** Bug 111827 has been marked as a duplicate of this bug. ***
*** Bug 111981 has been marked as a duplicate of this bug. ***
I have OS X on UFS and OS 9 on HFS. I run Mozilla for OS X from the HFS partition. I observe the difficulties already reported plus the following: Navigator does not accept URLs in the standard input field (in the symbol bar at the window top). I can enter URLs; they are displayed, but not processed. Entering URLs in a separate window (File/Open Web Location...) works. Regards, Michael
michael, do you have a build number? the location bar bug is not present in Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:0.9.6) Gecko/20011120, but is in 0.9.7 and 0.9.7+. i would give exact build numbers, except i can't launch more than one copy of mozilla at a time. i had asumed that the location bug was common, but was not able to find a bug for it. it is a *major* bug for me, and is keeping me to 0.9.6. first regression ever in mozilla harsh enough for me to prefer a older version. i am going to try starting from a hfs+ volume.
Blocks: 117359
http://lxr.mozilla.org/mozilla/source/xpcom/io/nsLocalFileMac.cpp#1196 that statement looks pretty suspicious. if slashes get converted to colons, then shouldn't all UFS paths start with a colon? pinkerton?
Mozilla/5.0 (Macintosh; U; Darwin Power Macintosh; en-US; rv:0.9.7+) Gecko/20011216 works.
so once conrad rewrites our file handling for mach-o, this will probably break again unless he fixes it in his rewrite. At least we know that the problem is probably in nsLocalFileMac. --> conrad, who is whacking all that stuff
Assignee: pinkerton → ccarlen
Status: ASSIGNED → NEW
Whiteboard: [OSX]
i have been noticing this for a while. mozilla (cfm) shows paths on ufs preceded with "/:". i tested same build, saving to a hfs volume and the path looked normal (not preceded by a slash, or a colon). i think the assumption made at http://lxr.mozilla.org/mozilla/source/xpcom/io/nsLocalFileMac.cpp#1190 is wrong (for ufs).
It's because yout boot disk is named / and you can't realy change it (if you logout then login the will be / back) it's a know bug for apple
sorry. my bad. i guess i was barking the wrong tree (probably).
Blocks: 123787
Michael Eibl's comments (Comment #25) are still valid for the latest OSX release of Mozilla 0.9.8 (Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:0.9.8) Gecko/20020205) (Build ID: 2002020516). Entering a URL in the location bar and pressing Return or Enter does not cause Mozilla to load the new URL, but using File -> Open Web Location... works fine.
*** Bug 122484 has been marked as a duplicate of this bug. ***
FWIW, the comment about root being '/' is a red herring. Mozilla-CFM will not run from an FFS volume even if it is not the root volume. It dies in the middle of launch at last check.
I posted this on netscape.public.mozilla.macosx, but it bears repeating here. HFS/HFS+ is case-preserving, but not case sensitive. UFS is case-SENSITIVE. Is it possible that somewhere in nsFileMac*.* there's a filename or pathname that is misspelled w.r.t. capitalization?
*** Bug 132116 has been marked as a duplicate of this bug. ***
*** Bug 132342 has been marked as a duplicate of this bug. ***
on my pure UFS formatted Mac OS X the Aqua Mozilla doesn't start indeed, but after compiling the Mozilla for X and running on top of XDarwin it works fine (after a minor glitch in the preferences, which vanished after once hand-editing them) as X application --- despite this can't tell for sure, where the bug lies withing, it makes it even more likely for me, that the problem is in Aqua/Apples API than in Mozillas --- safe for a misspelling in the Aqua component of Mozilla.
*** Bug 138343 has been marked as a duplicate of this bug. ***
at last I tested Chimera, a Mozilla/Gecko derived project in it's early stage with explicit Cocoa/Aqua integration like the OmniWeb browser, opposed to the Carbon stock Mozilla. And it just runs fine, despite it is rather alpha code so far and I had to handcode (opposed to the creators' mission!) the proxy settings in it... This strengthens the case, that the fault may lie within Mozilla itself though (see above, the XDarwin based Mozilla runs too on UFS). All nightly and the v1.0 release candidate official OS X builds failed so far to run from UFS...
Um, we know. The problem has nothing to do with Cocoa vs. Carbon. It's in the back end file system code. Chimera and X Darwin are using the *nix backend code for nsLocalFile (and NSPR) rather than the Mac specific code in MozillaCFM. We'll fix it eventually but since Apple's own docs say don't use UFS unless you have a specific need to we (still) consider this a minor bug.
*** Bug 124739 has been marked as a duplicate of this bug. ***
we know why the mach-o builds work and the cfm build doesn't. it's our nsLocalFile implementation. thanks for all the feedback, but we _know_ ;)
*** Bug 139935 has been marked as a duplicate of this bug. ***
*** Bug 140496 has been marked as a duplicate of this bug. ***
*** Bug 142417 has been marked as a duplicate of this bug. ***
*** Bug 145187 has been marked as a duplicate of this bug. ***
*** Bug 147271 has been marked as a duplicate of this bug. ***
"We'll fix it eventually but since Apple's own docs say don't use UFS unless you have a specific need to we (still) consider this a minor bug." Wrong, and wrong. Apple's rather old 10.0 docs said not to use UFS if you could help it. That's because a lot of stuff was broken on UFS in 10.0. That is no longer the case. In fact, I can only think of two programs that have don't like UFS. I'll be kind and not mention who the other one is.... Eighteen separate bug reports on a single bug says that this isn't a minor bug. That's a heck of a lot of independent reports for a single bug. I'm seeing a CC about a new dupe being added about once a week, and it seems to be becoming more and more frequent. Please consider this a high priority bug. If you don't fix this in a general way, you're just going to break again when people start putting their home directories on other filesystems with UFS-like semantics, like smb, nfs, potentially afp (Netatalk or Mac OS X afpd from a UFS partition), etc. I really don't want to be around when the education folks start adopting X in droves.... This bug is going to become a festering cess pool. :-)
I do not quite agree with 147271 being a duplicate of this. The UFS related bugs reported in Comment #12 (by danmcd@kebe.com) have been fixed in the meantime. Why should it not be possible to fix 147271 as well? On the other hand I fully agree with Comment #50 (by dgatwood@mklinux.org). Proper OS X support should include full support of UFS and other file systems. A fundamental solution of file system related bugs should be high priority. Regards, Michael
*** Bug 141084 has been marked as a duplicate of this bug. ***
Just got an iBook Friday, repartitioned and reinstalled (per <a href="http://people.debian.org/~branden/ibook.html">these helpful instructions</a>). So now I have an ext3, UFS, and HFS+ partition on this iBook. Oh, and /Home is being NFS mounted. <p> Mac OS X: 10.1.4 Mozilla: 1.0.0 RC 3 {Build ID: 2002041711} <p> It still doesn't work from UFS.
> It still doesn't work from UFS. Not surprising. Have you seen a patch on this bug or its resolution changed to FIXED? ;-) It should be fixed by bug 118203. Making dependent.
Status: NEW → ASSIGNED
Depends on: 118203
*** Bug 66255 has been marked as a duplicate of this bug. ***
summary: +startup
Summary: Unable to run Mozilla from a Macintosh UFS partition → Unable to run / startup Mozilla from a Macintosh UFS partition
Would moving this from Browser-General to XPApps or another Component be appropriate?
Yes. Should be XPCOM.
Component: Browser-General → XPCOM
*** Bug 157992 has been marked as a duplicate of this bug. ***
*** Bug 159677 has been marked as a duplicate of this bug. ***
This bug seems to be fixed by a patch applied on bug 118203 now --- see there for more details please, but I propose so far not to make it official, until a stable release working with ufs is out.
*** Bug 164916 has been marked as a duplicate of this bug. ***
cc self
*** Bug 165115 has been marked as a duplicate of this bug. ***
*** Bug 165073 has been marked as a duplicate of this bug. ***
This bug still exists on Mac OS X 10.2 I have tried with nightly august 27'th and 1.1 final and Netscape 7 final. **** Work Arround: For people with no HFS parition **** Mount your SMI disk image and run mozilla from virtual disk image. The application can still be launched and kept in the doc, just don't unmount the downloaded image. This allows people like me who don't have any HFS partition to still use the browser. Note, the profile and all functionalities of the browser work fine when run from the mounted image. It seems to save my bookmarks, settings, cache everything without any problem in my home directory.. it's only the launch of the app that seems to have a problem. It's just anoying having to run it in this manner.. please fix this bug. :)
*** Bug 168666 has been marked as a duplicate of this bug. ***
Any reason why this bug has been open for over a year and no one has even bothered to attempt to submit a patch or otherwise? This is a real issue for what is now a load of 10.2.1 users using UFS. Since bugs from 10.0 and 10.1 for UFS are now taken care of and thousands of other applications have NO PROBLEMS running UFS style, this just makes Mozilla look bad to the OS X community. This needs to be upgraded from a minor status and taken care of in a faster manner.
Jason: As far as I know, it is still around because no one at Netscape is running OS X on UFS. Also, I don't think anyone outside of netscape is building Fizzilla. Cocoazilla does not have the problem. These two facts mean that no one has access to both a UFS drive *and* a debug build of Fizzilla. If anyone has both of these, please feel free to speak up.
*** Bug 139374 has been marked as a duplicate of this bug. ***
Well, I just tried Moz on a UFS disk image with no problems (meaning it crashed like this bug is about), so the barrier to debugging this is lower than i thought. Still doesn't help me any as I have a UFS partition, but no debug build and no Codewarrior. How about it? Could we get some Netscape action on this?
Just tried Mozilla 1.2beta...still crashes on startup on my Jaguar w/ UFS.
Blocks: 179035
I just saw this for myself on MacOS 10.2.1. When you click on the icon, you get the Moz splash screen for just a second and then it goes away with no error message at all. As a Mac user I certainly don't feel very good about this. I feel even less good about everyone ignoring this.
After testing the new Mozilla 1.3 alpha the problem pertains --- despite there was a fix announced as to be found some time ago, it either didn't fix it really or was just not included into the Mozilla branches. (I'm aware, that neither Galeon nor Mozilla build on XFree nor Chimera have such a problem). So running Mozilla from the disk image (which works well, by the way) is my only solution at now. If I would have the time, I would try to fix this annoying bug myself, my Mac is fast enough for compiling it (Galeon and Mozilla on X were compiled there too) in reasonable time. Now I'm very dissatisfied with the behaviour of the responsibles, which I consider as rather unprofessional. Apple offers two filesystems as choice, and you have to support both of them therefore. And programming such a fs directly, sidestepping the VFS, is a no-no, of course; I suspect this was done opposed to classical UNIX systems like GNU/Linux. (don't resort to that outdated HFS+ is recommended argument, it has to mean nothing more meanwhile). I will make this topic public with a clear statement of critique on my homepage now (I'm software developer too, by the way), because I can't accept this way of ignoring a bug in the Mac specific parts of Mozilla, which isn't present in any UNIX version of it. It seems nearly ridiculous to me, that it is completely ignored.
Flags: blocking1.3b?
We're likely to be dropping the OS X CFM builds and moving to the Mach-O builds for 1.3 which I believe don't have this problem.
Flags: blocking1.3b? → blocking1.3b-
You are right about that, I guess: at least already a number of months ago the Mach-0 builds had no problem to run from UFS. When they are meanwhile stable and reliable enough, that will solve the problem indeed.
I have tested the latest Mach-0 build available, and from the former present problems only the not running Java plugin seems to persist. But Quicktime 6.02 and Flash 6 beta work and saving files does too (even this was broken in earliere Mach-0 builds, by the way).
This is a bug which was reported a year ago, yet Mozilla STILL does not run from a UFS volume. Why is this when Mozilla works fine under other BSDs on UFS filesystems? This should be properly documented as a bug until it is fixed. John Klos
RE: comment #78, this is because the mac os x versions of mozilla inherited the mac version's file handleing code, not the *nix version's. Also, this is documented in the release notes. From the Instalation Notes section: "Mac OS X: Mozilla will not run when the application is installed on a UFS partition. The workaround is to move the application folder to an HFS+ partition and it will run correctly." Still, I would agree that it should be under Known Bugs, rather than Instalation Notes.
Mach-O builds fix this.
*** Bug 189609 has been marked as a duplicate of this bug. ***
Blocks: 190979
You did it! As announced sometimes ago, the Mach-0 build, which always has run on UFS on OS X, works now fine as 1.3 beta even with Java and Flash support, correct download window behaviour (there was a minor flaw in BOTH build lines) and so on --- I have found no bug so far, and it seems it has become faster than 1.2.1. We can now close this bug finally I think, despite the problem was technically speaking more of being sidestepped (changing to another build line) than directly solved, but the result matters.
CFM died...
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → WONTFIX
Summary: Unable to run / startup Mozilla from a Macintosh UFS partition → Unable to run / startup Mozilla CFM from a Macintosh UFS partition
can anyone verify if this is still a problem so the release notes can be updated? (bug 197284)
Resolved with Mach-O. Regards, Michael
v
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: