From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8+) Gecko/20020212 BuildID: 2002021206 Reproducible: Always Steps to Reproduce: 1. Open Edit|Preferences 2. Click on 'Privacy & Security' twisty Actual Results: No extra options for 'Privacy and Security' appear! Expected Results: Normal display of children of that item

Sorry, just checked with more-recent nightly 2002021321 (linux) and this appears to have disappeared. Also found other problems, so this might have been an incomplete installation problem.

v

Seen this again on 20021321 linux, where I feel sure that it worked from initial installation. AFAICT after a crash: - original comment in this bug applies - the tasks menu has only navigator and composer (ditto status-bar shortcuts) Changing summary to reflect additional effects.

I am seeing this too on OpenVMS. Build id 2002021813. Static (UNIX) build. "Privacy & Security" has the right arrow head on the right side, but when you roll over the line, the flyout is just a small grey box. In the top section of the Tasks menu, only Navigator and Composer are visible. But I can start with the -mail option and the mail window comes up so that code is there. This sounds just like bug 120082, but I've checked my localstore.rdf file and all my "<RDF:li" tags have a closing ">".

Neil, you're not doing a static build by chance, are you?

Colin: I'm just using a standard mozilla nightly, probably using an installer. But this seems to happen only after a crash, at least that's my diagnosis so far...

More information. The tasks drop-down is correct when I first install Mozilla (all components are present and the "Privacy & Security" item expands correctly). But when I exit, second and all subsequent runs of Mozilla have the bad tasks drop-down. Note that I do NOT need to crash. I just install Mozilla, start it up, exit, and its broken. I can fix the problem by deleting chrome/chrome.rdf and components/xpti.dat. Then Mozilla will start up (once) correctly, but then its hosed again. So either my chrome.rdf or xpti.dat file is corrupt?

OK, I just have to delete chrome.rdf to fix the problem (for one run of mozilla).

Can't repro this bug as described in Colin's comment (comment 7). Is this a timing related issue with overlays? Maybe not cause it sounds specific to the "Privacy and Security" panel. Over to chrome registry folks for a look.

Can either of you, in a build with this problem, enter the following commands and attach them here. This smells like a permissions thing. $ cd <whereverTheBuildIsInstalled> $ cd chrome $ ls -l $ find . -ls $ id

$ ls -l -rw-r--r-- 1 eennjp eennjp 22651 Feb 13 22:27 US.jar -rw-rw-r-- 1 eennjp eennjp 26720 Feb 14 15:20 chrome.rdf -rw-r--r-- 1 eennjp eennjp 175840 Feb 13 22:27 chromelist.txt -rw-r--r-- 1 eennjp eennjp 258710 Feb 13 22:27 classic.jar -rw-r--r-- 1 eennjp eennjp 827512 Feb 13 22:27 comm.jar -rw-r--r-- 1 eennjp eennjp 3280 Feb 13 22:27 content-packs.jar -rw-r--r-- 1 eennjp eennjp 563516 Feb 13 22:27 en-US.jar -rw-r--r-- 1 eennjp eennjp 2747 Feb 13 22:27 en-mac.jar -rw-r--r-- 1 eennjp eennjp 4648 Feb 13 22:27 en-unix.jar -rw-r--r-- 1 eennjp eennjp 4678 Feb 13 22:27 en-win.jar -rw-r--r-- 1 eennjp eennjp 10154 Feb 13 22:27 forms.jar -rw-r--r-- 1 eennjp eennjp 12133 Feb 13 22:27 help.jar -rw-r--r-- 1 eennjp eennjp 196449 Feb 13 22:27 inspector.jar -rw-r--r-- 1 eennjp eennjp 10181 Feb 14 15:19 installed-chrome.txt -rw-r--r-- 1 eennjp eennjp 437771 Feb 13 22:27 messenger.jar -rw-r--r-- 1 eennjp eennjp 480631 Feb 13 22:27 modern.jar -rw-r--r-- 1 eennjp eennjp 485 Feb 13 22:27 pipnss.jar -rw-r--r-- 1 eennjp eennjp 92383 Feb 13 22:27 pippki.jar -rw-r--r-- 1 eennjp eennjp 234712 Feb 13 22:27 toolkit.jar $ find . -ls 401547 1 drwxr-sr-x 2 eennjp eennjp 1024 Feb 14 15:20 . 401548 10 -rw-r--r-- 1 eennjp eennjp 10181 Feb 14 15:19 ./installed-chrome.txt 401596 173 -rw-r--r-- 1 eennjp eennjp 175840 Feb 13 22:27 ./chromelist.txt 401633 814 -rw-r--r-- 1 eennjp eennjp 827512 Feb 13 22:27 ./comm.jar 401721 473 -rw-r--r-- 1 eennjp eennjp 480631 Feb 13 22:27 ./modern.jar 401737 4 -rw-r--r-- 1 eennjp eennjp 3280 Feb 13 22:27 ./content-packs.jar 401740 12 -rw-r--r-- 1 eennjp eennjp 12133 Feb 13 22:27 ./help.jar 401747 254 -rw-r--r-- 1 eennjp eennjp 258710 Feb 13 22:27 ./classic.jar 401751 231 -rw-r--r-- 1 eennjp eennjp 234712 Feb 13 22:27 ./toolkit.jar 401756 10 -rw-r--r-- 1 eennjp eennjp 10154 Feb 13 22:27 ./forms.jar 401770 431 -rw-r--r-- 1 eennjp eennjp 437771 Feb 13 22:27 ./messenger.jar 401771 1 -rw-r--r-- 1 eennjp eennjp 485 Feb 13 22:27 ./pipnss.jar 401772 92 -rw-r--r-- 1 eennjp eennjp 92383 Feb 13 22:27 ./pippki.jar 401773 5 -rw-r--r-- 1 eennjp eennjp 4678 Feb 13 22:27 ./en-win.jar 401774 5 -rw-r--r-- 1 eennjp eennjp 4648 Feb 13 22:27 ./en-unix.jar 401775 3 -rw-r--r-- 1 eennjp eennjp 2747 Feb 13 22:27 ./en-mac.jar 401776 555 -rw-r--r-- 1 eennjp eennjp 563516 Feb 13 22:27 ./en-US.jar 401777 24 -rw-r--r-- 1 eennjp eennjp 22651 Feb 13 22:27 ./US.jar 401779 193 -rw-r--r-- 1 eennjp eennjp 196449 Feb 13 22:27 ./inspector.jar 401745 28 -rw-rw-r-- 1 eennjp eennjp 26720 Feb 14 15:20 ./chrome.rdf $ id uid=1000(eennjp) gid=1000(eennjp) groups=1000(eennjp) I can't see that the g+w flag should be making a difference, but it certainly ties in with http://bugzilla.mozilla.org/show_bug.cgi?id=125489#c8

Hmm, no doesn't appear to be permissions. (Well, the setuid bit on the owning directory is unusual, but ...)

Just to confirm that with 2002022208 (linux) I see exactly the behaviour he mentions: ie. just closing down once and reloading: - makes Tasks menu (and status bar) only show browser and composer - makes privacy and security part of preferences be empty below the first level Possibly the second is related to the first, ie. 'unregistering' components other than browser and composer - if psm is not installed, would the privacy and security behaviour section be empty?

Still happening on OpenVMS will a tip build from the end of last week (2002022807). I need some clues, FAST, otherwise I can't ship M0.9.9!!!

Have you diffed working and non-working chrome.rdf? When do we write to the chrome.rdf file? During startup? During shutdown? (File timestamps should be good clues here.) Colin: you might want to spend some time in the debugger wherever we write out chrome.rdf, possibly backtracking from conditional breakpoints in the low-level file-writing code. Also, when did this start happening? Can you test older builds and narrow it down to a day? Help us help you! If this is a mozilla0.9.9 stopper, it should say so in the keywords at the least.

Even if I take chrome.rdf from my M0.9.8 installation it doesn't work in my M0.9.9 tree. When did it start exactly? Not known. Builds take so long on OpenVMS (30 hours) that I don't build very often. I noticed it with my first M0.9.9 build which was maybe a couple of weeks ago.

Some more info. If I search (grep) chrome.rdf for "chatzilla" (one of the missing components) in my M0.9.8 run tree, I find about 15-16 occurrences. But if I search in my M0.9.9 tree I don't find any. Even if I search as soon as Mozilla has first started up, when the RDF file is first written; there's no chatzilla. The "bad" RDF files looks about the correct size, about 28k bytes, but the contents are very different. And as I said before, if I copy chrome.rdf from my 0.9.8 tree into my 0.9.9 tree, I STILL don't get the missing components. Its like the damage is done during registration, and chrome.rdf just documents the damage. But then why does deleting chrome.rdf fix the problem (for one run)? That's the big clue for someone!

> But then why does deleting chrome.rdf fix the problem (for one run)? That's > the big clue for someone! If chrome.rdf does not exist (or the modtime on installed-chrome.txt is newer than chrome.rdf) then chrome registration will be run again at startup. This builds an in-memory model of the registry, which is also flushed to disk. On the next startup of the browser, the model is re-built from the contents of chrome.rdf and ./overlayinfo/*. So, what happens (I believe) is that the in-memory model is correct on the first run, the browser functions correctly (has the right overlays), but the flush somehow fails. Then, the second run will not work correctly because of this failed flush. [Or at least this is how I think it works from stepping through the code while looking at an earlier, related bug]. This may be the same bug as bug 126113. The problem being that we haven't figured out why this is failing on some systems and working on other, nominally similar, systems.

> When do we write to the chrome.rdf file? During startup? During shutdown? At startup, concurrent with building the model. [See below]. > Colin: you might want to spend some time in the debugger wherever we > write out chrome.rdf, possibly backtracking from conditional > breakpoints in the low-level file-writing code. The place to set a breakpoint is: http://lxr.mozilla.org/seamonkey/source/rdf/base/src/nsRDFXMLDataSource.cpp#823 which is in RDFXMLDataSourceImpl::Flush() called like this: RDFXMLDataSourceImpl::Flush() line 827 nsChromeRegistry::WriteInfoToDataSource() line 1399 nsChromeRegistry::UpdateDynamicDataSource() line 1447 nsChromeRegistry::UpdateDynamicDataSources() line 1498 nsChromeRegistry::InstallProvider() line 2090 nsChromeRegistry::InstallPackage() line 2393 nsChromeRegistry::ProcessNewChromeBuffer() line 3127 nsChromeRegistry::CheckForNewChrome() line 2998 nsChromeRegistry::Init() line 363 nsChromeRegistryConstructor() line 50 nsGenericFactory::CreateInstance() line 75 nsComponentManagerImpl::CreateInstance() line 1800 ...

> On the next startup of the browser, the model is re-built from the > contents of chrome.rdf and ./overlayinfo/*. I don't have the overlayinfo subdirtree in my 099 installation area. It never gets created. I think we're getting somewhere!! I don't have a debug build for 099 (and building one would take 30 hours) but I can trace. If I delete chrome.rdf in my 098 tree and run Mozilla, the first time I see any action in overlayinfo is a stat() of /dka0/work/m098opt/chrome/overlayinfo/communicator/content/overlays.rdf. But if I do the same in my 099 tree I don't see that stat(), just an open() attempt (in fact many of them) to that file, plus many other overlayinfo files. So, when is the overlayinfo subtree is written out, and why isn't it happening sometimes?

I found the real problem. Its not creating the subtree directories in 099. If I manually create ./chrome/overlayinfo/communicator/content/ directory then I get Mail & Newsgroups and Address book components. As part of the way I create a kit on OpenVMS, I don't package empty directories (never have done). This is why they don't exist on OpenVMS. And I always install into a brand new area, so they are not left over from a previous version. So, it looks like we lost the ability to create the overlayinfo directory structure.

Just to confirm that under 2002022208 linux, I have no subdirectories in ./chrome! What did you mean by 'manually create', Colin? During the install, or just creating them afterwards?

Neil, do something like this: rm ./chrome/chrome.rdf mkdir -p ./chrome/overlayinfo/communicator/content mkdir -p ./chrome/overlayinfo/editor/content mkdir -p ./chrome/overlayinfo/inspector/content mkdir -p ./chrome/overlayinfo/messenger/content mkdir -p ./chrome/overlayinfo/navigator/content Then run Mozilla and you should be all set.

Colin: Thanks, that seems to have worked fine. So how hard can this be to fix? This is just a case of changing the tar command line used to package the binaries, right? I'm wondering whether other directories are also missed in this way; could this cause xpi's to fail to install properly too? I'm thinking of bug 109044, for example...

This sounds like essentially the same problem as Bug 126113 (as mentioned in comment 18). Although I'm not sure that fixing tarballs is the solution; I'm seeing this problem with the installer (unless the installer is just untarring tarballs, but that doesn't seem to be the case).

I believe the installer creates those directories if they don't already exist. That's no doubt why most people don't see this. But OpenVMS has never used the installer, so I KNOW that Mozilla used to create these on the fly if needed. That's what's changed.

No, the installer does not create them (or at least not always). That's the problem I reported in Bug 126113. I almost always use the installer version of the nightlies, and I've been having this problem with every one of them for some time. If the installer is supposed to be creating them, it's broken.

I did an LXR search for overlayinfo earlier http://lxr.mozilla.org/seamonkey/search?string=overlayinfo and what came back lead me to believe that the installer would create the directories. But I didn't look too closely at the code.

Well, it's entirely possible that it is *supposed* to create them, but it demonstrably does not create them on any of the systems I use Mozilla on. Perhaps we have two problems here. First that the installer isn't creating the dirs when it should and second that Mozilla isn't creating them when/if it finds them missing...

> So, when is the overlayinfo subtree is written out... I should have been more complete in my statement above. The overlayinfo/* subdirectories, and leaf contents.rdf files, are created at the same time that the chrome.rdf file is created: dynamically, the first time the browser is run in a new installation.[1] Note: the installer does _not_ create (chrome.rdf|overlayinfo/*), the browser itself does. The code you saw in the lxr search does not apply to this situation. > I found the real problem. Its not creating the subtree directories in 099. > If I manually create ./chrome/overlayinfo/communicator/content/ directory > then I get Mail & Newsgroups and Address book components. Okay. Good. The code which creates the overlayinfo/* subtree was changed in bug 113894, to not use a nsFileSpec, and instead to use nsIFile. As of Jan 31 (Feb 01 builds), it will call |nsIFile->Create(nsIFile::NORMAL_FILE_TYPE, 0666);| before it flushes to that file (which seems a bit wasteful, but that's a different issue). The implementation on Unix is supposed to create the ancestor directories if they don't exist (see nsLocalFileUnix::Create / nsLocalFileUnix::CreateAllAncestors) There are a number of DEBUG_NSIFILE printfs in those routines that could be forced on in an optimized build (or via define in debug builds). It would be very useful if we had the output of those printf's for a system where this fails. To test correctly, (1) shut down the browser, (2) delete <binarydir>/chrome/chrome.rdf and <binarydir>/chrome/overlayinfo/*, if they exist. This will cause chrome registration to happen on the next browser startup. (3) start the browser. Chrome registration will happen, and the LocalFile printf information will show in the console. Hopefullly that will show where this fails. cc: dougt for nsIFile issues. ------ [1] or, if installed-chrome.txt modtime in newer than chrome.rdf modtime, then chrome registration is run again.

Unfortunately, I can't seem to reproduce this with a debug build from source I built last night. Yet it persists in the prepackaged nightly builds. Part of the difference here is, of course, that I'm downloading Linux nightlies but the versions I'm building are native FreeBSD versions. I don't have a Linux system to build on, so I can't get a Linux debug version to test with. If someone can get me a debug linux build from recent source with the appropriate defines to get the printf output we want, I'll test with it.

I defined DEBUG_NSIFILE in nsLocalFileUnix.cpp, rebuilt that module, relinked libxpcom.so, copied it to my run area, deleted the chrome stuff, ran Mozilla. No output. Not sure why. I'm tired. Will try again in the morning.

Interestingly, if I copy that image to one of my webservers and load it from there, it loads fine. So it looks like there must be some difference in how the server is responding.

Oops! Wrong bug for that last comment. Sorry.

-> dougt, Networking::File I'm quite sure that what is failing is nsIFile::Create on the affected platforms. It would help immensely if someone on a platform that is affected could force the DEBUG printfs on, even just hacking that into an optimized build, and report back with what they say.

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

Like I said in Comment #31, if someone can build a Linux build with those printfs enabled and give it to me, I'll do some debugging. But I can't reproduce the problem in the builds I've done. I can always reproduce it in Linux nightlies, so it should show up in a Linux build from the nightly source.

Sean- could you try one of the nightlies that are produced with a newer compiler (this includes the RPM's, the gcc295 nightlies, and the gcc3 nightlies) and see if the problem exists there? Perhaps there's a compiler bug in the mix here.

Also, this might be one of those rare times when strace provides useful debugging information. You'll get an enormous log, but there might be gems in there.

I'll see what I can do about trying a different build. I just downloaded a gcc3 build and am apparently missing a shared library, but I may be able to work that out. As for strace/truss, which process do I want to trace? I.e. at what point in the process do I want to put the trace command?

could someone update the summary to more closely reflect the root problem?

I tried with DEBUG_NSIFILE defined in nsLocalFileUnix.cpp again. No output at all. Nothing. I don't think any of that code is getting called. By anyone.

OK, here's the problem (I had to put in some more DEBUG_NSIFILE print statements because NONE of the existing ones ever get hit!). nsLocalFile:Create calls the create function and if, and ONLY if, it fails with ENOENT does it then call CreateAllAncestors. On OpenVMS we fail with an OpenVMS specific error EVMSERR and that's why we never create the parent directories.

That diagnosis don't seem to hold up for FreeBSD (where I'm seeing the problem) or Solaris (where Roland is seeing the problem)...

Also, as far as I can tell, both exclusive_create and exclusive_mkdir should be returning -1 with errno set to ENOENT on my machine if the directory doesn't exist. I just tested with a small program and they do that (including with programs compiled on Linux).

The next point of failure is as it tries to create the tree. What does mkdir("/top") return with? The only accepted failure is -1/EEXIST so if your system returns something else for an existant directory, you're SOL.

mkdir() on /top returns -1 with errno == EACCES (permission denied). Since I don't have write permission to /, that seems to be an appropriate result. Did you mean "/tmp"? In that case, I actually also get EACCES. Trying to mkdir() a directory that already exists in my home dir (where I do have write access, obviously) does result in -1/EEXIST...

By /top I meant whatever the top of your install tree is. If you have installed Mozilla to /usr/users/fred/mozilla then mozilla will first try mkdir("/usr") and it expects -1/EEXIST to come back if it already exists. If your system comes back with -1/EACCES because you don't have write access to the root directory, TOUGH! You're going to fail. I'm hitting this problem now on OpenVMS (after fixing the first problem).

Ahh! Ok, sorry. I understand now. And yes, that is a problem here. It may be a bug in FreeBSD's Linux emulation? If I run the test binary on Linux, I get -1/EEXIST. If I run it on FreeBSD, I get -1/EACCES. If I compile it natively on FreeBSD and run it, I get -1/EEXIST. So mkdir() is behaving differently under Linux emulation. I'm going to try to dig down some more info on why this is and what can be done about it. It seems that a workaround might be to stat() the directory before trying to create it to see if it exists. I don't think the extra 3 or 4 stat() calls would introduce much of a performance hit or anything.

NO!! Please, no more stat calls. I have other bugs submitted to get all the unnecessary stat calls removed.

First problem. In nsLocalFile::Create just checking for the specific failure of ENOENT is to specific (OpenVMS fails with a different error). So I've changed it to basically accept any failure so that it will then try to create the directory tree. The worst that will happen is that I'll try to create an existing directory tree and then when it tries to create the original file again it'll fail again. We'll catch the error then. #if defined(VMS) if (result == -1 && errno != EEXIST) { #else if (result == -1 && errno == ENOENT) { #endif Second problem. nsLocalFile::CreateAllAncestors will accept EEXIST as an error when creating the tree. Any other error and it aborts the tree creation. OpenVMS is returning EINVAL on the mkdir of the topmost directory. I've changed this so that can error is accepted and we keep walking down the file path trying to create directories as we go. If we really aren't able to create the tree, we'll know when we return to Create the original creat()/open() that we retry fails again. #if !defined(VMS) if (result == -1 && errno != EEXIST) return NSRESULT_FOR_ERRNO(); #endif The above two fixes fix the problem. But I really need to see if I can get the UNIX emulation in VMS to do a better job in these cases, so that I don't need to ifdef nsLocalFileUnix.

heh. Ok, fair enough. I think this is a bug in FreeBSD anyway, and I'm pursuing that.

If your system doesn't return UNIX-standard (SVr4, POSIX, SYSV, X/OPEN and others all agree on the sets of codes to return) error codes, then maybe your system shouldn't be using nsLocalFileUnix. (Please don't bloody up nsLocalFileUnix.cpp with ifdefs; we already have too many because of the BEOS weenies.) The EACCES issue is a bug in nsLocalFileUnix, though, and I probably caused it. We should probably just ignore errors in attempting to create the parent directories. I recall considering that, and deciding that I wanted to only ignore specific errors in pursuit of better error reporting to the caller. (If we're trying to create /usr/some/thing and /usr doesn't exist, the problem is really EACCES, but if we just plow on through we'll hand back ENOENT.) But o standard specifies what error should be returned if several error conditions are met, so we have to either stat on error to see if it really does exist and continue, or just march on and hope. I think the right thing is to stat and check, but ignoring errors is certainly easier. (Stat overhead in the error case is uninteresting, please don't even bother.)

Just to clarify: a bug in FreeBSD linux emulation. Mozilla compiled on FreeBSD doesn't have this problem. BTW: stat is cached in the nsLocalFileUnix implementation. --pete

Right, native FreeBSD binaries don't have the problem, which is why I couldn't reproduce it with builds I did myself. Unfortunately, nightly FreeBSD builds come much less often than Linux builds and I have neither the free disk space nor the time to regularly build my own from source, so I'm stuck with using Linux binaries if I want to keep up with the nightlies.

I haven't seen any evidence in this bug of a bug in FreeBSD, or its Linux emulation. There are two bugs that we've found: - VMS uses nsLocalFileUnix, but doesn't provide Unix error semantics, and should therefore use nsLocalFileVMS, where EVMSERR and other VMSisms can be handled properly. - nsLocalFileUnix makes, likely at my hands, invalid assumptions about error codes provided for some directory-creation scenarios. It should either verify those assumptions through stat calls or not try to check for such specific failure cases.

While nsLocalFileUnix may also have a bug (or at least not handle errors as well as it should), the evidence of a bug in FreeBSD is thus: A simple mkdir("/home",(mode_t)0755) on Linux results in EEXIST A simple mkdir("/home",(mode_t)0755) on FreeBSD (native) results in EEXIST A simple mkdir("/home",(mode_t)0755) on FreeBSD (linux emulation) results in EACCES The mkdir() call under emulation should result in the same error that it does natively in Linux. Even to result in the same error as natively in FreeBSD would make more sense than the current result.

Which Linux kernel version and filesystem semantics is the emulation claiming to provide? I doubt Linux's behaviour has always been the same, across all versions and filesystems. Feel free to report this "bug" to the maintainers of the FreeBSD Linux emulation, if you want, though. I suspect they'll tell you the same thing, but one never knows with the BSD crowd. =)

Good point. I really have no idea. FWIW, the behavior is the same in 2.4.7 and 2.2.16. I didn't test beyond that.

For OpenVMS I am trying to resolve this problem by making our "UNIX emulation layer" return the expected status codes. This is the only real solution if I want to keep VMS using nsLocalFileUnix.

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

retargeting as I will not have any time to work on it. Please reassign if you like.

Still present in 2002030607 (linux i386) :( As a temporary hack (ie. leave the bug open, but 'fix'), could the installer not just automatically create the files? This would (I hope) work for all the 'standard' directories; I'm not sure if this bug affects installation of additional compononents too. But something like this would stop mozilla looking pretty dire on some fairly common platforms. BTW, not sure if anyone else on linux sees this bug, but I'm on a 2.0 kernel; I wouldn't have thought that this should make a difference, since the API functions in question are in libc, and I'm currently on 2.2.5!

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

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

I'm seeing this bug with the Solaris build of 20002040310. The Privacy and Security item has children when mozilla is run the first time after a fresh install, but then has no children upon subsequent invocations.

Just wondering: One if the bugs marked as duplicate of this bug was a "smoketest"-blocker. Shouldn't this one be a smoketest blocker, too (at least it prevents people from using mailnews the normal way...) ?

Roland: which bug? Anyone: please update the summary to reflect the "File" aspect of the problem. If there is a installer problem that can be defined, can someone make sure there is an installer bug, or create one if needed?

Benjamin Chuang wrote: > Roland: which bug? AFAIK bug 126113 > If there is a installer problem that can be defined, can someone make sure > there is an installer bug, or create one if needed? This is not an installer bug, this happens when you start the Zilla directly after building from dist/bin/, too ...

(like I was saying, it isn't apparent to me what is going on here...)

I believe I found out what's going on in my case. NSIFile tries to create the ancestors of /chrome/overlay/... but because there is an autofs mountpoint in the middle it gets ENOSYS instead of EEXIST (this is from the truss output): 12093: open64("/usr/local/groups/sysadmin/products/mozilla/0.9.9.tt/mozilla/chrome/overlayinfo/communicator/content/overlays.rdf", O_RDONLY) Err#2 ENOENT 12093: open("/usr/local/groups/sysadmin/products/mozilla/0.9.9.tt/mozilla/chrome/overlayinfo/communicator/content/overlays.rdf", O_WRONLY|O_CREAT|O_TRUNC|O_EXCL, 0666) Err#2 ENOENT 12093: mkdir("/usr", 0777) Err#17 EEXIST 12093: mkdir("/usr/local", 0777) Err#17 EEXIST 12093: mkdir("/usr/local/groups", 0777) Err#89 ENOSYS 12093: open64("/usr/local/groups/sysadmin/products/mozilla/0.9.9.tt/mozilla/chrome/overlayinfo/communicator/content/overlays.rdf", O_WRONLY|O_CREAT|O_TRUNC, 0664) Err#2 ENOENT 12093: open("/usr/local/groups/sysadmin/products/mozilla/0.9.9.tt/mozilla/chrome/overlayinfo/communicator/content/overlays.rdf", O_WRONLY|O_CREAT|O_TRUNC|O_EXCL, 0666) Err#2 ENOENT 12093: mkdir("/usr", 0777) Err#17 EEXIST 12093: mkdir("/usr/local", 0777) Err#17 EEXIST 12093: mkdir("/usr/local/groups", 0777) Err#89 ENOSYS 12093: open64("/usr/local/groups/sysadmin/products/mozilla/0.9.9.tt/mozilla/chrome/overlayinfo/communicator/content/overlays.rdf", O_WRONLY|O_CREAT|O_TRUNC, 0664) Err#2 ENOENT .... The test around line 320 in nsLocalFileUnix.cpp: 320 if (result == -1 && errno != EEXIST) 321 return NSRESULT_FOR_ERRNO(); is far too simple minded.

kuenne@rentec.com: what OS (exactly) are you using?

In fact, that's exactly the problem explained in Comment 51 through Comment 59 in this very bug... We're going in circles :-)

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

Stealing from dougt...

Requesting r=/sr=/a= ...

Roland: while I'm sure getting solaris working is a good thing, is there a similar fix for linux (and VMS?). I do appreciate the target->1.0 change, just confirming that the intention is to fix all platforms ;)

Neil: thanks for thinking of VMS!!! On this particular one we seem to be UNIX-like enough that things actually work.

Neil Pilgrim write: > while I'm sure getting solaris working is a good thing, is there a > similar fix for linux (and VMS?). I do appreciate the target->1.0 change, just > confirming that the intention is to fix all platforms ;) Sure, no problem. Please figure-out which errno value is returned by your automounter if you try to do a mkdir() at that mountpoint (do not forget to comment which automounter package do you use - Linux has (AFAIK) three different automounters). But I would perfer to check the current patch "in" ASAP to get the Solaris platform back to life... - we can keep this bug open to fix all the other platforms, too...

>Sure, no problem. Please figure-out which errno value is returned by your >automounter if you try to do a mkdir() at that mountpoint (do not forget to >comment which automounter package do you use - Linux has (AFAIK) three >different automounters). AFAIK I don't use an automounter ;) Does that help? ;( >But I would perfer to check the current patch "in" ASAP to get the Solaris >platform back to life... - we can keep this bug open to fix all the other >platforms, too... I guessed this might be the case, but just checking ;)

My problem is that it's returning EACCES. I don't think that EACCES should be a fatal error in this case; it should go on to try to create the next level down. Fatal errors would be things like ENOENT (which would happen on the next level down if the EACCES actually did mean we couldn't create that dir), ELOOP, EROFS, ENOSPC, EDQUOT, EIO, etc...

I've just been trying the test mentioned earlier: doing mkdir("something") and seeing what the result is. The problem is that the following fails to compile due to mkdir requiring two arguments. I've not used this function before - could someone suggest the best second argument, and I can then do the requisite tests... #include <sys/stat.h> #include <stdio.h> int main(void) { printf("%d = return of mkdir(\"/top\")\n",mkdir("/top")); }

Doh, sorry, should have looked at previous messages first...'0777' being suggested :) Sorry...

OK, I'm not sure whether my analysis is correct, but here's the results of my initial testing (in order): - mkdir("/home/",0755) fails with -1:EACESS - mkdir("/home/user",0755) fails with -1:EACCES - mkdir("/home/user/foo/bar",0755) fails with -1:ENOTDIR (ahem, foo exists!) - mkdir("/home/user/fooz/bar",0755) fails with -1:ENOENT - mkdir("/home/user/fooz",0755) suceeds! - mkdir("/home/user/fooz/bar",0755) suceeds! I understand this is part of the process moz goes through in the code in question (well, almost!); if correct, can the code be corrected to account for the behaviour I see? BTW as I said before, this is with libc(6) 2.2.5, so it should be sufficiently up-to-date :) [even with a 2.0.x kernel ;)]

The patch works for me on Sparc Solaris 7. Thanks Roland!

dougt: Care to r= the patch, please ?

Comment on attachment 78574 [details] [diff] [review] Patch for 2002-04-09-08-trunk to get the Solaris platform working again The patch looks fine, however, I would rather blizzard@redhat.com, shaver@mozilla.org, or brendan@mozilla.org give you a r= since their nix fs fu is greater than mine. Specifically, I wonder if we should also be trapping EACCES, or EROFS?

The patch won't help the VMS problem unless it works around the EINVAL on the top mkdir() call. Maybe errno!= EINVAL? I think the linux on FreeBSD needs an errno !=ENOENT test. But what should mkdir return in these cases? Solaris returns EEXIST if the file is local, but if it's an NFS mount point, it gives ENOSYS. I noticed Solaris here has a mkdirp() function that looks like the mkdirhier command, but I don't see it in linux (glibc-2.2.5)

DougT: Primary issue (for me :) is to get Solaris working again - and then look how to kill this issue for all other "punished" platforms using a clean solution, too...

I looked in the solaris mkdir(2) man page and it doesn't mention ENOSYS, but intro(2) does. It mean operation is not applicable. So it must be related to the automounter. I don't have a Solaris box I can use to move mozilla to a no-automounted dir, but the directory I have mozilla in, is a local filesystem automounted to /home/$USER without using NFS. This is probably a bug in the automounter. It should return EEXIST if the directory exists. Could we walk backwards, until we get EEXIST then mkdir() the needed parts? Can we just start at <moz-dir>/chrome, and start there since we know it exists (already opened the jar files there)?

Let's not fix this piecemeal, we have enough diagnosis to do the right thing for 1.0 on all afflicted platforms. /be

In my testing so far OpenVMS is working fine with the code the way it currently is. I did change some stuff in the OpenVMS "unix layer" to make some of the returns more unix-like though :-)

I checked the mkdirhier command (script in /usr/openwin/bin/mkdirhier) in Solaris 8, and it call stat on the elements, starting with the dir entry in /, then it forks() like this: stat64("/home", 0xFFBED0B0) = 0 stat64("/home/ted", 0xFFBED0B0) = 0 stat64("/home/ted/mozilla", 0xFFBED0B0) = 0 stat64("/home/ted/mozilla/check", 0xFFBED0B0) Err#2 ENOENT brk(0x0003D5A0) = 0 stat64("/home/ted/mozilla/check /home/ted/mozilla/check/dir /home/ted/mozilla/check/dir/creation", 0xFFBECE08) Err#2 ENOENT fork() = 12724 waitid(P_PID, 12724, 0xFFBED048, WEXITED|WTRAPPED|WNOWAIT) = 0 The fork is to the standard mkdir. Should we just do a stat on each part until we find the part we need?

Brendan Eich: > Let's not fix this piecemeal, we have enough diagnosis to do the right thing > for 1.0 on all afflicted platforms. Not fixing this issue will make MailNews, Editor, CharZilla etc. unaccessible on the Solaris platform. I _STRONGLY_ suggest to fix this issue (that's why I took this bug from dougt...) before we ship 1.0 ...

HOw is this suggestion. we *could* ignore mkdir errors all together. If the stat() fails on the terminal node, we then map this error to some nsresult. I mean, what does it gain us to short circuit the mkdir loop? Is this stuff called often enough to make this a performance problem?

> Not fixing this issue will make MailNews, Editor, CharZilla etc. unaccessible on > the Solaris platform. And fixing it the way you've suggested will leave all of those things inaccessible on FreeBSD and possibly other platforms. That's not a solution.

Sean Harding wrote: > > Not fixing this issue will make MailNews, Editor, CharZilla etc. > > unaccessible on the Solaris platform. > > And fixing it the way you've suggested will leave all of those things > inaccessible on FreeBSD and possibly other platforms. That's not a solution. I only wanted to fix the issue platform-per-platform unless someone comes up with a better solution... ... and the stat()-before-mkdir() seems to be a good solution for this issue on all platforms... :)

Roland, Here is where we will have to butt heads: you say that it makes all these thing unavailable for the "Solaris" platform. You know darn well I build and use my Solaris builds daily and even put them out for distribution, this problem does not affect anything other than NFS mounted versions of mozilla on "nix" so I would say this is a critical issue for 1.0 but I think when we make a fix it should encompass all *nix's not just Solaris. -my 2 cents -dcran-

> this problem does not affect anything other than NFS mounted > versions of mozilla on "nix" False. I've never even tried it on NFS. It happens on local disk (UFS) to me.

Ok, Here I build mozilla on both Solaris 8 and Solaris 9 nightly, I provide builds to mozilla.org. These builds do not have the problems you are referring to. I use the Forte 7 compiler.

Donnie, tahnks fior the nightlies. I use them. The problem in Solaris is with the way the automounter works. (mkdir() on an automount controlled dir returns ENOSYS instead of EEXIST) In many environments $HOME is automounted, so it's in the same place on all machines. For me /home/ted is automounted. It's a local disc, exported by NFS from it's normal /export/nd01 location. If I go to another machine, it's NFS mounted on /home/ted too. So the automounter causes user installs of mozilla to fail in $HOME. If it was in /usr/local, and usr/local was automounted, it would fail everywhere it's used. If it's in /opt, and /opt is automounted, same problem. automounted $HOMEs is very common. It would kill mozilla based apps on many networks. I agree the Solaris issue is probably a bug in Solaris. but a simple fix, that can be backed out later is better than non-accessable mail, news, addressbook, and security modules. Other platforms have similar problems, like VMS with out tweaking their Unix emulation layer. Or linux-on-FreeBSD.

Donnie, I'm not disputing that the problem only exists on NFS for *Solaris*. That's all that the evidence you've presented proves. Your blanket statement that it only exists on NFS for all Unix is absolutely incorrect, though. You can't take your experience with Solaris builds and assume that what's true of them is true for everything else. If you has said, "this problem does not affect anything other than NFS mounted versions of mozilla on Solaris," I wouldn't have a problem. But you said, "this problem does not affect anything other than NFS mounted versions of mozilla on 'nix.'" And that just isn't true.

Comment on attachment 80114 [details] [diff] [review] New patch for 2002-04-14-08-trunk - stat()-before-mkdir() solution with comments and reference to this bug r=dougt

Comment on attachment 80114 [details] [diff] [review] New patch for 2002-04-14-08-trunk - stat()-before-mkdir() solution with comments and reference to this bug Use access, not stat, if you want a cheap existence check. But this is still racy and, I think, not as good as a simple errno whitelist after an unconditional mkdir. IOW, if errno is not one of {EPERM,EACCES,ENAMETOOLONG,ENOTDIR,ENOMEM,EROFS,ELOOP,ENOSPC,EIO,EMULTIHOP,ENOL INK} (those last two nightmares from SVR4, and you may have to #ifdef-test for each) then carry on, otherwise return the nsresult for the errno in that whitelist. /be

Sure, the errno whitelist is longer, but it may hold up across more platforms and over time, compared to a blacklist. However, if we can come up with a blacklist (EEXIST, ENOSYS, EVMSERR if it's defined, what else?) that works as well, do that -- but don't stat or access(2) before mkdir. /be

We won't forget this for 1.0RC2. /be

Brendan Eich wrote: > Sure, the errno whitelist is longer, but it may hold up across more platforms > and over time, compared to a blacklist. However, if we can come up with a > blacklist (EEXIST, ENOSYS, EVMSERR if it's defined, what else?) that works as > well, do that -- Using the E* values may not be a portable solution since some Unix variants define non-standard values (and use them, too). Using this way would always require to dump <sys/errno.h> for each single platform we want to support and always need to adjust nsLocalFileUnix.cpp Is this really neccesary ? > but don't stat or access(2) before mkdir. Why ? Performance can't be the reason since this code isn't called much in the lifetime of a mozilla-bin process...

Brendan Eich wrote: > But this is still racy and, I think, not as good as a simple errno > whitelist after an unconditional mkdir. There is (please correct me if I am wrong) a minor glitch in this logic. mkdir() is an atomar filesystem operation - but we are calling it multiple times anyway to create a directory hieracy in this case. Our "mkdirhier" can never be an atomar operation - and trying to avoid any access()/stat() etc. will not make it atomar.

Hi Guys, this seams to have broken on Solaris again, however there is no chrome/chrome.rdf file to remove as suggested before anyone any suggestions? as a work around this is using mozilla 1.rc1 release...

Infact on second untarring there is NO mail or extra functions available... is this a true rc1 build? thanks Toby.

mkaply: sorry i'm 99% sure this is the bug you're looking for.

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

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

Comment #113 is not correct. I should not try such stuff at 2.00am ... =:-) Another solution: What about a |access()-after-mkdir()|, e.g. run mkdir() - and if it fails check if the dir already exists. If it exist then continue to create the next directory level - but when the dir does not exist then return the error from mkdir() to the caller... brendan: Would you take such a solution ? This solution will only be a problem if someone _deletes_ the dir between the mkdir() and the access() call...

I have some more information on this. When our OS/2 users have found this, the issue is that one over the overlays.rdf files has become all 0's. The size of the file is exactly the same, it's just that all the content is gone. So doing a directory, you would not notice it. We have verified this with two people. So we need to figure out how overlays.rdf could get overwritten. The browser works fine and then suddenly one of the overlays.rdf is messed up. No one can find a scenario that causes it to happen. I have a copy of one of the messed up overlays.rdf. The one in question was editor.

My observations also seen on Solaris 2.8 rc1 build (I do not see this on Linux): After second start, no mail window entry in any menu; Also privacy and security missing in preferences; but mail starts by itself if nav and mail are choosen as startup windows; but when starting mozilla with option '-name Mozilla',only nav comes up. Menu entries come back when deleting component.reg and chrome.rdf in installation directory, but disappear again after next start. No difference in the general behaviour if starting with fresh or old .mozilla user directory. Maybe these odd observations give some clues.

Proceeding as in comment #23 and removing chrome/chrome.rdf, component.reg and .mozilla/.../chrome/chrome.rdf, restarting, resetting theme, if desired, and restarting brings all missing components and menu entries back. This script to start Mozilla could serve as a temporary workaround on Solaris 8 (the XSUNTRANSPORT prevents hangs with Suns PatchCluster 1, can be removed if on nearly native Solaris, but install at least the patches mentioned in the release notes): ----------- snip ------------------------------ #!/bin/sh XSUNTRANSPORT=noshmem export XSUNTRANSPORT MOZILLA_HOME="your path"/mozilla <==== change export MOZILLA_HOME OVERLAY=$MOZILLA_HOME/chrome/overlayinfo mkdir -p $OVERLAY/communicator/content $OVERLAY/editor/content $OVERLAY/inspecto r/content $OVERLAY/messenger/content $OVERLAY/navigator/content $MOZILLA_HOME/mozilla $* 2>.moz_error 1>/dev/null & ------------- snap ----------------------------- When starting directly after installation, the necessary registration entries in overlay/ can be written.

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

The previous patch did not convert the |errno| from |mkdir()| to |nsresult| in all cases...

OK, we now have two working solutions to kill this bug _FOREVER_. I let the reviewer/superreviewer make the choice which patch should "go in" ... :) Requesting r=/sr= ...

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

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

Comment on attachment 80885 [details] [diff] [review] Better patch for 2002-04-21-08-trunk - access()-after-mkdir() solution >diff -N -r -u original/mozilla/xpcom/io/nsLocalFileUnix.cpp mozilla/xpcom/io/nsLocalFileUnix.cpp >--- original/mozilla/xpcom/io/nsLocalFileUnix.cpp Wed Mar 20 04:16:09 2002 >+++ mozilla/xpcom/io/nsLocalFileUnix.cpp Thu Apr 25 01:54:27 2002 >@@ -306,7 +306,20 @@ > #ifdef DEBUG_NSIFILE > fprintf(stderr, "nsIFile: mkdir(\"%s\")\n", buffer); > #endif >- int result = mkdir(buffer, permissions); >+ int mkdir_result = mkdir(buffer, permissions); >+ int mkdir_errno = errno; >+ if (mkdir_result == -1) { >+ /* Always set |errno| to EEXIST if the dir already exists Follow the major comment convention in the file, like so: /* * Always set |errno| to EEXIST if the directory already exists >+ * (we have to do this here since the errno value is not consistent >+ * in all cases - various reasons like different platform, >+ * automounter-controlled dir, etc. can affect it (see bug 125489 >+ * for details)). >+ */ >+ if (access(buffer, F_OK) == 0) { >+ mkdir_errno = EEXIST; >+ } >+ } 1. Use four-space indentation per the c-basic-offset modeline. >+ Please, no trailing whitespace on an empty line, and no double empty line (this one above that has trailing whitespace should be deleted). > This pre-existing, space-free line is enough. > /* Put the / back before we (maybe) return */ > *slashp = '/'; >@@ -317,8 +330,8 @@ > * ENOTDIR when we try to make the next component in the path, > * either here on back in Create, and error out appropriately. > */ >- if (result == -1 && errno != EEXIST) >- return NSRESULT_FOR_ERRNO(); >+ if (mkdir_result == -1 && mkdir_errno != EEXIST) >+ return nsresultForErrno(mkdir_errno); > } > > #ifdef DEBUG_NSIFILE I like this approach, in general -- it optimizes, rather than pessimizing by always calling stat or access first. When I wrote "racy", I meant any race, I did not say or imply that some sequence of system calls here is atomic. /be

Comment on attachment 81601 [details] [diff] [review] New patch for 2002-04-27-08-trunk (access()-after-mkdir() solution) per brendan's comments r=dougt running with the patch since yesterday and have not noticed anything abnormal. Lets get this on the trunk and shoot for geting this for mozilla 1.0

Roland, time is short. Please get this landed on the trunk quickly. If that doesn't happen very quickly it will not make RC2

Asa Dotzler wrote: > Roland, time is short. Please get this landed on the trunk quickly. If that > doesn't happen very quickly it will not make RC2 superreview-request is out (http://groups.google.com/groups?dq=&hl=en&group=netscape.public.mozilla.reviewers&safe=off&selm=3CCFD5E5.66C41BEB%40mac.com) - AFAIK I cannot do much more, right ?

Comment on attachment 81601 [details] [diff] [review] New patch for 2002-04-27-08-trunk (access()-after-mkdir() solution) per brendan's comments sr=brendan@mozilla.org, thanks -- there's still time, go strong. /be

Patch checked in into "trunk" (http://bonsai.mozilla.org/cvsquery.cgi?module=MozillaTinderboxAll&branch=HEAD&cvsroot=/cvsroot&date=explicit&mindate=1020294180&maxdate=1020294960&who=timeless%25mac.com) ...

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

[idea from comment #89:] Filed bug 141631 ("RFE: Use |mkdirp()| on Solaris to create directory hieracies...") to use |mkdirp()| instead of our home-grown stuff on platforms where this function is available (e.g. Solaris) ...

Taking bug for approval/checkin per drivers

Comment on attachment 81601 [details] [diff] [review] New patch for 2002-04-27-08-trunk (access()-after-mkdir() solution) per brendan's comments a=scc for checkin to the Mozilla1.0 branch

Fix checked into 1.0 branch

Annoucement (since nearly half of Sun engineering is CC:'ed to this bug... :) Follow-up for Solaris is bug 141631 ("RFE: Use |mkdirp()| on Solaris to create directory hieracies...") - it may be nice to test the upcoming patch for that bug (just to make sure that I do not regress anything... =:-) ...

adding branch resolution keyword

I've reviewed all the bugs that were marked as duplicates: A couple administrative items: 1- Better summary is needed, how about: "nsLocalFileUnix error handling improvements"? 2- Which component owns component registration? Also, which component owns the chrome registration stuff that jrgm explains? Probably most of the duplicates go there. I'm going to review the duplicates that were found, but I am going to leave them with their original components. 3- Verification plan: My skills are limited in this area, so I'm going to verify by consensus. This is basically a "code change" bug, but it affect so many people in serious ways, so I'm going to use the emperical approach. I'd like one representative from each platform that reported to confirm this fixes their problem (VMS, FreeBSD, Solaris and OS/2).

This fixed it for me in FreeBSD.

can't verify for solaris, because current nightly refuses to start with linker error: "ld.so.1: /usr/local/mozilla/mozilla-bin: fatal: libCstd.so.1: open failed: No such file or directory." which is clear because the lib isn't there. will investigate further

We have separate bugs for the OS/2 issues. We are still trying to figure them out. We don't think it is the same thing.

Markus Wernig wrote: > can't verify for solaris, But I can verify it for Solaris - it works on my Solaris 2.7 SPARC machine... :) > because current nightly refuses to start with linker > error: "ld.so.1: /usr/local/mozilla/mozilla-bin: fatal: libCstd.so.1: open > failed: No such file or directory." which is clear because the lib isn't > there. You have one (or more) of the following problems: - The package "SUNWlibC" which contains libStdC.so.1 is not installed. - You are missing a lot of the Recommended&Security patches from Sun for your OS (BAD!) - You have an OS which does not ship with this library (like Solaris 2.5.1)

Michael Kaply wrote: > We have separate bugs for the OS/2 issues. We are still trying to figure them > out. What's the bugid of that bug ?

We have two OS/2 issues that we think are this problem. http://bugzilla.mozilla.org/show_bug.cgi?id=130569 http://bugzilla.mozilla.org/show_bug.cgi?id=136040 We're still investigating what's going on. The overlays.rdf file is being overwritten with nulls, but we're not convinced that Mozilla is the one doing it.

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

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

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

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

VERIFIED: platform reporters said everything worked. Please reopen if I did this wrong. Please file new bugs if you have new problems, even if they look similar.