SMB_QUERY_FILE_ALL_INFO not correct in SNIA spec?

Richard Sharpe rsharpe at richardsharpe.com
Wed Feb 19 06:30:44 GMT 2003


On Tue, 18 Feb 2003, Joey Collins wrote:

> The SNIA definition of the data required for SMB_QUERY_FILE_ALL_INFO
> does not appear to be correct. Furthermore, Ethereal's interpretation
> does not seem right, either. 

That is quite possible. We often rely on the SNIA doc, and then change 
things if they don't look quite right. I recall messing with one of the 
QUERY_FILE info levels because the attributes displayed were clearly 
wrong.
 
> Here's what SNIA says:
> 
>     TIME  CreationTime;
>     TIME  LastAccessTime;
>     TIME  LastWriteTime;
>     TIME  ChangeTime;
>     ULONG Attributes; // SNIA says USHORT; Ethereal says ULONG
>     LARGE_INTEGER AllocationSize;
>     LARGE_INTEGER EndOfFile;
>     ULONG NumberOfLinks;
>     UCHAR DeletePending;
>     UCHAR Directory;
>     LARGE_INTEGER IndexNumber;
>     ULONG EaSize;
>     ULONG AccessFlags;
>     LARGE_INTEGER IndexNumber1; // mistake in SNIA spec?
>     LARGE_INTEGER CurrentByteOffset;
>     ULONG Mode;
>     ULONG AlignmentRequirement;
>     ULONG FileNameLength;
>     STRING FileName[];
> 
> After poking around with a sniffer, here is what I think it looks 
> like:
> 
>     TIME    CreationTime;
>     TIME    LastAccessTime;
>     TIME    LastWriteTime;
>     TIME    ChangeTime;
>     ULONG   Attributes; 
>     ULONG   Pad1;  // assumed
>     LARGE_INTEGER AllocationSize;
>     LARGE_INTEGER EndOfFile;
>     ULONG   NumberOfLinks;
>     UCHAR   DeletePending;
>     UCHAR   Directory;
>     USHORT  Pad2; // assumed
>     ULONG   EaSize;
>     ULONG   FileNameLength;
>     STRING  FileName[];

One wonders why they needed a ULONG Pad in there. Perhaps it is just 
something we don't understand as yet.

> This is simply the concatenation of Basic Info, Standard Info (plus 
> padding, Pad2, which is not in the SNIA spec), EA Info, and 
> File Name Info. There is no sign of the rest of the information
> (internal file system index numbers, open-file information) being
> present.
> 
> In my test I used a Win 2000 client, a Win 2000 server, and used
> SMB_COM_QUERY_FILE_INFORMATION (by fid, not by path).
> 
> My questions:
> 
> 1) Can anyone else confirm my interpretation?

If you can send us a capture, we can look at it to see if we agree with 
your interpretation, and perhaps modify Ethereal as well.

> 2) Are there server-dependent variations on the format?

There should not be any server-dependent variations that cannot be 
determined by looking at WordCount or Protocol Dialect.

Regards
-----
Richard Sharpe, rsharpe[at]ns.aus.com, rsharpe[at]samba.org, 
sharpe[at]ethereal.com, http://www.richardsharpe.com



More information about the samba-technical mailing list