Re: CIFS improvements/wider testing needed

[Steve French]

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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/