Internal base file opens using incorrect access mask?

[Hemanth Thummala]

Hi All,

While debugging an issue, I have come across the code where we try to open
the base file with access mask zero and  oplock set to none. This is
getting registered as shared mode lock for the base file.

Here is the snippet of code  in create_file_unixpath() which shows this.

......
                /* Open the base file. */
                status = create_file_unixpath(conn, NULL, smb_fname_base,
0,===> access mask
                                              FILE_SHARE_READ
                                              | FILE_SHARE_WRITE
                                              | FILE_SHARE_DELETE,
                                              base_create_disposition,
                                              0, 0, 0, 0, 0,==> oplock NULL,
NULL,
                                              &base_fsp, NULL);

......



Where as in find_oplock_types(), we are filtering out shared mode locks
from these internal opens using access mask of
(SYNCHRONIZE_ACCESS|FILE_READ_ATTRIBUTES| FILE_WRITE_ATTRIBUTES).

Ideally this lock should have been filtered out as internal/stat open in
find_oplock_types() as suggested by following piece of code.

...
 if (lck->share_modes[i].op_type == NO_OPLOCK &&
                                is_stat_open(lck->share_modes[i].access_mask))
{
                        /* We ignore stat opens in the table - they
                           always have NO_OPLOCK and never get or
                           cause breaks. JRA. */
                        continue;
                }

...

If you check the code for is_stat_open()..

....
bool is_stat_open(uint32 access_mask)
{
        return (access_mask &&
                ((access_mask & ~(SYNCHRONIZE_ACCESS| FILE_READ_ATTRIBUTES|
                                  FILE_WRITE_ATTRIBUTES))==0) &&
                ((access_mask & (SYNCHRONIZE_ACCESS|FILE_READ_ATTRIBUTES|
                                 FILE_WRITE_ATTRIBUTES)) != 0));
}

...

Because of this problem I have seen an oplock test(stream1) failure. Test
is passed after fixing the access mask.
Please let me know if my observations are correct.

I have created a bug 10283 for the same issue.You can find more information
as part of this bug.


Thanks,
Hemanth.