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

Status: RESOLVED FIXED

(NSS :: Libraries, defect, P2)

Description

[Bishakha Banerjee]

Occurs in both DBG and OPT builds.

Comment 1

[Bishakha Banerjee]

Attachment: results.html of DBG build

Comment 2

[Bishakha Banerjee]

Attachment: output log of DBG build

Comment 3

[Bishakha Banerjee]

Attachment: output log of OPT build

Comment 4

[Wan-Teh Chang]

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
read-write.

-=-=-=-= 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);
        exit(1);
    }
    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

[Wan-Teh Chang]

Attachment: Proposed workaround

Comment 6

[Wan-Teh Chang]

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.

Comment 7

[Nelson Bolyard (seldom reads bugmail)]

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.

Comment 8

[Bishakha Banerjee]

Verified this particular test passed on tip nightly QA. Marking Fixed.

Comment 9

[Wan-Teh Chang]

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

[Bishakha Banerjee]

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?