[linux-cifs-client] Re: POSIX Unlink and Query Unix File Info2

[Steve French]

James Peach wrote:
> On 09/03/2007, at 1:47 PM, Jeremy Allison wrote:
>
>> On Fri, Mar 09, 2007 at 03:44:47PM -0600, Steve French wrote:
>>> If server supports CIFS_UNIX_POSIX_PATHNAMES_CAP then
>>> SMB_POSIX_PATH_UNLINK MUST be available? or SHOULD be available?
>>
>> Must.
>>
>>> I saw a comment in your code indicating that this did an oplock break
>>> and is path only (not SetFileInfo).   Does this mean that if we have 
>>> the
>>> file open on the client - there is a handle based way to get posix
>>> semantics on delete of a file ... seems like we must if the path based
>>> one should break oplock
>>
>> Yes, that's the case.
>>
I certainly want to make sure there is a way for a client to delete the 
open file without break oplock

>>> If server supports CIFS_UNIX_POSIX_PATHNAMES_CAP then
>>> SMB_QUERY_FILE_UNIX_INFO2 MUST be available? or SHOULD be available?
>>
>> I think it's a should. James, George - comments ?
>
> To follow up, I don't think that any info level should ever be a MUST. 
> The client MUST always be prepared for any info level to fail 
> (particularly the more recent ones).
>
>
This is tricky ... we don't want to have the client retry unnecessarily 
- it could be a performance disaster if every lookup took two requests.

| I made it so that CIFS_UNIX_EXTATTR_CAP indicates the availability of 
SMB_QUERY_FILE_UNIX_INFO2,

I don't mind this as long as it also controls level 0x206 (trans2 
query/set ATTR_FLAGS)