Closed Bug 53014 Opened 19 years ago Closed 19 years ago

fix for various file open errors

Categories

(Core :: XPCOM, defect, P1, blocker)

x86
BeOS
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: hiro, Assigned: ykoehler)

Details

(Whiteboard: [nsbeta3-])

Attachments

(6 files)

Mozilla opens a lot of files that live under dist/bin such as various
resource files. Currently, none of them gets properly loaded because
the current process directory (which in this case is '.') is not normalized
before it's used, and nsLocalFileUnix has incomplete BeOS implementation of
nsLocalFile::Normalize() method. The patch follows.
Status: UNCONFIRMED → NEW
Ever confirmed: true
If I interpretted the new checkin rules correctly, I should be able to nsbeta3+
this bug.  It is essential for any forward movement on the BeOS port and the
changes are entirely BeOS-specific.

Severity: normal → blocker
Priority: P3 → P1
Whiteboard: [nsbeta3+]
The above patch must be applied at the same time Hiromasa's is applied.

Recent changes (to workaround a BeOS limitation) to PR_LoadLibrary only correctly checked relative filenames.  When Hiromasa's above patch is applied, it breaks PR_LoadLibrary.  The above patch properly handles absolute and relative filenames.
In the patch id=14901 there seems to be a bug.  THere's a '}' with a ';' after it.  if() {};That won't compile I think... The ';' should be removed.
I am in Boston for 4 days, so the earliest I could look at it would be Friday.  
Feel free to ask Scott Collins (scc@mozilla.org) or Doug Turner 
(dougt@netscape.com) to look at it before then.
Status: NEW → ASSIGNED
Target Milestone: --- → M18
Don't apply any of the patches mentioned here yet. It looks like it
didn't work for other people. My patch might have just aliased the
culprit and didn't really fix it.
PDT marking nsbeta3-
Whiteboard: [nsbeta3+] → [nsbeta3-]
I'm going to reassign this to Yannick as he's handling the BeOS port issues with
his handy-dandy new cvs account. :-)
Assignee: rayw → koehler
Status: ASSIGNED → NEW
I had to tweak Matt's prlink patch to work if only the basename of the library
was passed to PR_LoadLibraryByPathname().  I'm not sure why only the basename
was being passed but it was failing the strcmp() check. 

I know this was discussed in passing in the newsgroup, but I think Hiromasa's
changes were on the money.  We do need to call Normalize() before we can use any
paths. With these changes and the ones from 55271 & 55450, I was able to get
windows up now.
Status: NEW → ASSIGNED
I will clarify all those patch into one, then request a review of it.  All those patches are confusing.
I need someone to take this patch, I don't have access to NSPR.  

Also the patch to commit are #3 (09/24/00 20:30) and #4 (10/09/00 05:08)
There appears to be substantial difference between the NSPRPUB_CLIENT_BRANCH and 
the tip of the NSPR tree. The CVS logs are a bit confusing as to why there is 
such a difference. ... Anyway, I reworked cls's patch to fit prlink.c on the 
nspr tree tip. The question is: is this what was intended? cls, please review.
I believe the reason for the discrepancy between the client branch and the nspr
tip is because the fix for bug 51655 was never commited to the tip. I'd suggest
applying the patch from 51655 then the one I attached.  It should apply cleanly
after that.

The reworked patch probably won't compile because of the extra |+| inside the
|while (get_next_image_info(0, &cookie, &info) == B_OK) {| loop.
Checking into NSPR_CLIENT_BRANCH
Checking in prlink.c; 
/cvsroot/mozilla/nsprpub/pr/src/linking/prlink.c,v  <--  prlink.c
new revision: 3.34.2.7; previous revision: 3.34.2.6
done

Checking into NSPR tree tip
Checking in prlink.c;
/cvsroot/mozilla/nsprpub/pr/src/linking/prlink.c,v  <--  prlink.c
new revision: 3.45; previous revision: 3.44
done
Warren, can we get a r= for the 3rd attachment?  The changes are completely
within a XP_BEOS ifdef.
I'm not qualified to review a BeOS patch. However, I did notice a stray '+' sign
on this line:

     +				char *endOfSystemName = strrchr(info.name, '/');
Ok, I guess I'll give it the r=cls since I've tested Hiro's revised patch and
verified that it works.  (Question still remains, can I give a r= to a module
I'm not a owner or peer of?)

Warren, can we get a module owner approval to check these changes in?
scc, can we get a sr?
Reviewing the patch of 09/24/00 20:30.  Use |PL_strncpyz| and avoid the extra
work to terminate (which was not necessarily putting the terminator in the right
place anyway).
looks good.  sr=scc
Keywords: patch
The updated version of Hiromasa's patch has been checked in.  Marking fixed.
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
v
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.