[jcifs] Possible bug in jcifs.smb.SmbComOpenAndX

[Andy Thomson]

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.

---

Thank you for the fast reply.

Andy


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
>