Closed Bug 169506 Opened 22 years ago Closed 20 years ago

nsLocalFileUnix have problems with BeOS. IsExecutable()...

Categories

(Core :: XPCOM, defect)

x86
BeOS
defect
Not set
normal

Tracking

()

RESOLVED FIXED
Future

People

(Reporter: sergei_d, Assigned: thesuckiestemail)

References

Details

(Keywords: helpwanted)

Attachments

(2 files, 3 obsolete files)

For example, access() POSIX function returns always 0, inspite real status/mode. (used in IsExecutable, IsWritable, IsReadable) This is partly bugginess, partly specifics of BeOS POSIX layer implementation. For example, http://bugzilla.mozilla.org/show_bug.cgi?id=145860 depends on this bugginess. I think that right idea is to fork at last nsLocalFileBeOS from nsLocalFileUnix and starting step-by-step rewrite.
feel free to reasign to a beos owner.
Keywords: helpwanted
Target Milestone: --- → Future
setting dependency
Blocks: 145860
Attached patch Patch for IsXRW group of methods (obsolete) (deleted) — Splinter Review
Using stat() instead access()
Comment on attachment 100758 [details] [diff] [review] Patch for IsXRW group of methods sr=scc. I think this requires module owner review from dougt with an analysis (or at least an explanation) from dougt as to why |stat| instead of |access|.
Attachment #100758 - Flags: superreview+
or rather, why not |stat| instead of |access| universally, so that separate implementations aren't needed...
Comment on attachment 100758 [details] [diff] [review] Patch for IsXRW group of methods according to sergei_d@fi.tartu.ee, access is buggy on BeOS. r=dougt if you put a comment under the #ifdef XP_BEOS stating this. btw, do you require me to check this in?
Attachment #100758 - Flags: review+
"btw, do you require me to check this in?" Yes, i do, because i haven't permissions.
Attached patch Patch with comment (deleted) — Splinter Review
Same as previous, but has comment after #ifdef BEOS
Attachment #100758 - Attachment is obsolete: true
I can check this in tonight, as I've been told that I am the port lead for BeOS and have CVS access.
great. over to you...
Assignee: dougt → arougthopher
Comment on attachment 101730 [details] [diff] [review] Patch with comment Opps. Additionaly removed warning (sometimes even compile error) about assigning const char * Path() to char * resolved_path_ptr in XP_BEOS part of NS_IMETHODIMP nsLocalFile::Normalize()(get tired to fix such things every time manually - explicit casting is Good Thing (TM)).
Doug, does it need r= again? Scott allowed me to forward sr from previous patch.
Comment on attachment 101730 [details] [diff] [review] Patch with comment r=arougthopher sr=scc (as per sergei's comments) I will check this in as soon as the tree re-opens
Attachment #101730 - Flags: superreview+
Attachment #101730 - Flags: review+
This has been checked in.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Reopening, the patch commited does not take into account that ENOENT should not return an error.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Blocks: 266252
Patch to fix ENOENT, also includes correct behaviour for Reveal, Exists is also moved away from the buggy access implementation.
Reassigning to tqh. I'm looking at it right now.
Assignee: beos → thesuckiestemail
Status: REOPENED → NEW
1. It doesn't apply cleanly on the MAIN branch (your name is rejected) Please note that the formatting of the header has changed (make sure you check it) 2. Your second hunk deletes a newline. Why? 3. In the third hunk you have two newlines between Exists() and IsWritable(). 4. Could you explain why ENOENT is a good condition? If you have a path that doesn't exist, how can you say it is writable? Remember, I'm just nagging. This is shared code and it should look as nice as possible. One small question though. Exactly what kind of bugs does this fix?
Blocks: 276378
(In reply to comment #18) > 1. It doesn't apply cleanly on the MAIN branch (your name is rejected) > Please note that the formatting of the header has changed (make sure you > check it) > 2. Your second hunk deletes a newline. Why? > 3. In the third hunk you have two newlines between Exists() and IsWritable(). > 4. Could you explain why ENOENT is a good condition? If you have a path that > doesn't exist, how can you say it is writable? > > Remember, I'm just nagging. This is shared code and it should look as nice as > possible. One small question though. Exactly what kind of bugs does this fix? 1. Ah well I'm still on AVIARY unfortunatly so I have to get the new tree. 2. 3. Because I've done major work and checking and those slipped thru. 4. These functions are defined as 'do not fail if not existant'. Just return false. At least that's how they are used under Windows / Unix and the access documentation says the same so I assume that's correct.
It fixes downloading, Otherwise you will get a lot of JS-crashes in some JS file if you don't specify 'Ask me where to save'. Probably Downloads.js. It may not show without bug 276378 applied. Also it probably fixes a lot under the hood.
Attached patch Updated to HEAD - still the same patch by tqh (obsolete) (deleted) — Splinter Review
Attachment #169808 - Attachment is obsolete: true
Comment on attachment 170048 [details] [diff] [review] Updated to HEAD - still the same patch by tqh >-#ifdef XP_BEOS >-// access() is buggy in BeOS POSIX implementation, at least for BFS, using stat() instead >+ > NS_IMETHODIMP > nsLocalFile::IsWritable(PRBool *_retval) > { > CHECK_mPath(); > NS_ENSURE_ARG_POINTER(_retval); > struct stat buf; > *_retval = (stat(mPath.get(), &buf) == 0); > *_retval = *_retval && (buf.st_mode & (S_IWUSR | S_IWGRP | S_IWOTH )); >- if (*_retval || errno == EACCES) >+ if (*_retval || errno == EACCES || errno == ENOENT) 'errno' should be read only if a library function call has failed. If the stat() call succeeds (returns 0) but the file is not writable, the above code will set *_retval to 0, and proceed to read errno (for comparison with EACCES and ENOENT). In this case, the value of errno is garbage.
Ah, good point, I was going to say that we have the 'stat(..) == 0' in there but then on the next line we may set *_retval to false anyway. I'll fix that during the day.
tqh, could you fix this patch? I'd really like to include it (working) in a next build. Thanks.
Yes, in fact I thought I already had, but I see now that I never uploaded it here. Thanks for reminding me.
Attached patch Updated patch (deleted) — Splinter Review
This should be the latest version. I am having some troubles with my computer, so not 100% sure. Also tried to improve formatting and added a reference to this bug so that we know why this was done.
Attachment #170048 - Attachment is obsolete: true
Comment on attachment 171405 [details] [diff] [review] Updated patch I believe this one to be ok, r?
Attachment #171405 - Flags: review?(sergei_d)
Comment on attachment 171405 [details] [diff] [review] Updated patch r=sergei_d Hope no more buggy access() cases for BeOS
Attachment #171405 - Flags: review?(sergei_d) → review+
Comment on attachment 171405 [details] [diff] [review] Updated patch sr?
Attachment #171405 - Flags: superreview?(dougt)
Comment on attachment 171405 [details] [diff] [review] Updated patch looks fine.
Attachment #171405 - Flags: superreview?(dougt) → superreview+
Checked in by timeless
Status: NEW → RESOLVED
Closed: 22 years ago20 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: