Re: CIFS improvements/wider testing needed

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



VALETTE Eric RD-MAPS-REN wrote:

Steve French wrote:
VALETTE Eric RD-MAPS-REN wrote:

Steve French wrote:


Eric,
Well I would be surprised the "cat >> titi" command does any of this
byte range lock. If the "create and later rewrite the same file"
sequence fails, with a simple cat command (cat > titi ... ^D; cat >>
titi), how can it works with complicated applications?



Make sure that you let me know if your cat example works when mounted
with the relatively new "noperm" mount option on the client.   At least
then we will know whether we are looking at a problem with access
control on the server (ntfs acls) or client (unix mode bits and the
.permission entry point)

Works with the "noperm" mount option.

--eric

Could you run "stat titi" and/or "ls -l titi" between the
   "cat > titi"
and the
   "cat >> titi"

so I can see what cifs thinks the owner of the file is and the mode. I also need to know the current user so I can see whether it matches what cifs has as the owner of the file. Note that readdir (ls of a directory or ls with a wildcard) and lookup (ls of a specific file, or stat) hit different code paths in the cifs vfs but both cause default mode bits to be put in the inode metadata.

If this does not point out the problem, then I will give you a modified version of cifs_permission to trace what is happening.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux