[cifs-protocol] Re: File Attributes in NT_CREATE_ANDX

Matt Seitz seitz at neopathnetworks.com
Thu Feb 8 16:00:41 GMT 2007

Adam Simpkins wrote:
> On Tue, Feb 06, 2007 at 08:11:10PM +0000, Joseph Kuan wrote:
>> However, the first one NT_CREATE_ANDX has File Attributes: 0x00000000 
>> and the second one has value 0x00000080.
> Are these the attributes in the request or the response?
> Microsoft's documentation says the
> ATTR_NORMAL bit (0x80) indicates that this is a "normal" file with no
> other attribute bits set.  It seems redundant to me, but clients and
> servers normally send 0x80 instead of just 0x0.
>> I expect both File Attributes 
>> have values, 0x00000080, such that the bit for "Normal: This file is an 
>> ordinary file" is set. Strangely, the one with zero value have different 
>> label, "Normal: This file has some attribute set".
> This is probably just how ethereal chooses to label the values.  As
> far as I know there isn't any real semantic difference.

Perhaps "0x00000080" means either "clear all attribute bits" or "open only if 
file has no attribute bits set", while "0x00000000" means something like "don't 
modify attribute bits", or "open regardless of whether an attribute bit is set" 
or "open only if an attribute bit is set".

My guess is that this packet implements the CreateFile Win32 API command.  That 
contains a "FlagsAndAttributes" bitfield parameter, with one bit flag being 
"FILE_ATTRIBUTE_NORMAL".  My guess is that calling CreateFile with 
"FlagsAndAttributes" set to FILE_ATTRIBUTE_NORMAL generates a packet with File 
Attributes set to 0x00000080 and setting "FlagsAndAtrributes" to 0 genrates a 
packet with File Attributes set to 0x00000000.

I did a quick read of the MSDN documentation for CreateFile, and it wasn't clear 
to me what the difference in semantics was for 0x00000080 vs. 0x00000000.

More information about the cifs-protocol mailing list