Re: CIFS improvements/wider testing needed

From: Steve French
Date: Tue Nov 22 2005 - 11:40:52 EST


Steve French wrote:


Steve French wrote:


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.


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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at