Closed Bug 86538 Opened 23 years ago Closed 22 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: 22 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: