[jcifs] Possible bug in jcifs.smb.SmbComOpenAndX

[Michael B Allen]

On Thu, Aug 27, 2009 at 2:07 PM, Andy Thomson<a10008051 at gmail.com> wrote:
> Mike,
>
> Yup.  Mr Murphy smacked me in the head.  A little while after sending
> the email, I figured out what was going on  ... of course the comments
> in the code could not possibly have been a hint :-O ...  To avoid my
> future confusion on it, I renamed it comflags. I was just doing some
> "what if" experiments, that's how I got there.
>
> ---
>
> I did spot some duplicate static declarations in the SmbFile, some that
> it actually picks up from SmbConstants. They are harmless, just duplicated.
>
>  public static final int ATTR_READONLY = 0x01;
>   ...
>  // extended file attribute encoding(others same as above)
>  static final int ATTR_COMPRESSED = 0x800;
>  static final int ATTR_NORMAL = 0x080;
>  static final int ATTR_TEMPORARY = 0x100;
>
> These appear in both SmbConstants and SmbFile.

I have added this to the todo.

Thanks,
Mike

> Michael B Allen wrote:
>> On Thu, Aug 27, 2009 at 9:58 AM, Andy Thomson<a10008051 at gmail.com> wrote:
>>> Mike,
>>>
>>> It looks like that the declared "int flags" in SmbComOpenAndX is not used, and
>>> it may be stepping on the declared "byte flags" from ServerMessageBlock.  This
>>> appears to be the case in the writeParameterWordsWireFormat() method.
>>>
>>> I did not find any "upstream" usages of it [int flags], and the lower ones
>>> reference the correct ServerMessageBlock one [byte flags].  This one [int flags]
>>> is not set, which implies that the writeParameterWordsWireFormat() is always
>>> seeing a default setting, and never the intended one, at least not that I can
>>> tell.  ServeMessageBlock does call the writeParameterWordsWireFormat() method
>>> via the encode() method, not sure the result is always what was intended.
>>>
>>> The class SmbComOpenAndX extends AndXServerMessageBlock, and
>>> AndXServerMessageBlock extends ServerMessageBlock.  ServerMessageBlock has a
>>> variable "byte flags" defined in it.
>>>
>>> class SmbComOpenAndX extends AndXServerMessageBlock {
>>>  ...
>>>
>>>  int flags,               <<< should be removed ???
>>>  desiredAccess,
>>>  searchAttributes,
>>>  fileAttributes,
>>>  creationTime,
>>>  openFunction,
>>>  allocationSize;
>>>
>>>  ...
>>>
>>>  int writeParameterWordsWireFormat( byte[] dst, int dstIndex ) {
>>>    int start = dstIndex;
>>>
>>>    writeInt2( flags, dst, dstIndex );   <<< which flag? use empty
>>>                                             local one? or one from
>>>                                             ServerMessageBlock?
>>
>> Hi Andy,
>>
>> No, it should not be removed. But I can understand why you're
>> confused. There is a 'byte flags' of ServerMessageBlock.java that
>> represents the 'Flags' field in the SMB header. But SMB_COM_OPEN_ANDX
>> also has a 'Flags' field which is completely different and for our
>> purposes is always 0. And because the local 'int flags' is not
>> explicitly initialized, it should be 0 which is the correct value that
>> should go out on the wire. The field should probably be called
>> something else but I tried to follow the naming convention set by the
>> Leach Naik draft so the name 'flags' just happened to be the same.
>>
>> Are you experiencing a particular problem? Are you trying to set the
>> SMB_COM_OPEN_ANDX flags? Currently there is no way to set that field
>> since it's used for oplocks and stuff we don't use. That command as a
>> whole is also largely obsolete. If you're doing command-level
>> programming, try to use SMB_COM_NT_CREATE_ANDX.
>>
>> Mike
>>
>



-- 
Michael B Allen
Java Active Directory Integration
http://www.ioplex.com/