If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

MacOSX 20021212.1 QA "Dbtest r/w succeeded in an readonly directory" failure



15 years ago
15 years ago


(Reporter: Bishakha Banerjee, Assigned: Wan-Teh Chang)


Mac OS X

Firefox Tracking Flags

(Not tracked)



(4 attachments)



15 years ago
Occurs in both DBG and OPT builds.

Comment 1

15 years ago
Created attachment 109146 [details]
results.html of DBG build

Comment 2

15 years ago
Created attachment 109147 [details]
output log of DBG build

Comment 3

15 years ago
Created attachment 109148 [details]
output log of OPT build

Comment 4

15 years ago
I found that this is a bug in the NFS implementation for
Mac OS X.

Here is a test program that opens the specified file for

-=-=-=-= openrw.c -=-=-=-=-=
#include <fcntl.h>
#include <stdio.h>
#include <errno.h>
#include <stdlib.h>

int main(int argc, char **argv)
    int flags = O_RDWR;

    if (open(argv[1], flags) == -1) {
        fprintf(stderr, "open failed: %d\n", errno);
    printf("open succeeded\n");
    return 0;
-=-=-= end openrw.c -=-=-=-=

Compile the test program with this command:

% cc openrw.c -o openrw

Then run this script.

-=-=-=-=-= test.sh -=-=-=-=-=
rm -f ro.txt
touch ro.txt
chmod a-w ro.txt
ls -l ro.txt
#sleep 10
./openrw ro.txt
./openrw ro.txt
./openrw ro.txt
-=-=-=-= end test.sh -=-=-=-=

If you run the test script in an NFS-mounted directory,
you'll see that the first attempt to open the readonly
file for read-write succeeds, but the second and third
attempts fail with the expected error (EACCES=13).

% sh test.sh
-r--r--r--  1 wtc  eng1  0 Dec 12 17:18 ro.txt
open succeeded
open failed: 13
open failed: 13

If you run the test script in a local directory, all
three open attempts fail with EACCES.

% sh test.sh
-r--r--r--  1 wtc  wheel  0 Dec 12 17:20 ro.txt
open failed: 13
open failed: 13
open failed: 13

If you uncomment out the "sleep 10" statement in test.sh,
the test will also produce the expected result in an
NFS-mounted directory.  So it seems that it takes several
seconds for the "chmod a-w" command to take effect even
though "ls -l" immediately reports the new file permissions.

Comment 5

15 years ago
Created attachment 109185 [details] [diff] [review]
Proposed workaround

Comment 6

15 years ago
In the interest of time I've checked in the workaround
on the trunk so that it will be tested in tomorrow's
daily QA.  I'd still appreciate a code review.

Ideally we should submit a bug report to Apple.
Assignee: relyea → wtc
Priority: -- → P2
Target Milestone: --- → 3.7
Comment on attachment 109185 [details] [diff] [review]
Proposed workaround

Assuming that opening the files once solves it, this patch should do the trick.
 Of course, having to take special precautions to get the OS to recognize that
it's now R/O seems utterly bogus, so maybe it would be better to just skip this
test on MacOS/X.  But this patch should also work.
Attachment #109185 - Flags: review+

Comment 8

15 years ago
Verified this particular test passed on tip nightly QA. Marking Fixed.
Last Resolved: 15 years ago
Resolution: --- → FIXED

Comment 9

15 years ago
I just checked in the workaround on the NSS_3_7_BRANCH.

We could also work around this NFS bug by doing a
"sleep 10".  I am just concerned that it would make the
test run longer and on a heavily loaded system 10 seconds
may not be long enough.

Comment 10

15 years ago
spd17, which we are testing on now, is pretty heavily loaded, and the plans are
to run Tinderboxes and nightly QA both on bijou, which would load it up.
Probably better to keep it this way?
You need to log in before you can comment on or make changes to this bug.