file size parsed/passed incorrectly/incompletely in cli_qpathinfo*()

[Derrell.Lipman at UnwiredUniverse.com]

In tracking down why smbc_stat() is returning the wrong size of files when
the files exceed 4GB in size, I have discovered these problems:

P1. size_t is used for storing file sizes internally.  Unfortunately, it does
    not seem that size_t changes to 64 bits (on Linux) when LARGEFILE64_SOURCE
    is defined and _FILE_OFFSET_BITS=64 is specified.  Although size_t was
    traditionally used as the type of a variable which holds a file size, the
    proper type these days (at least on Linux; unverified elsewhere) is off_t
    which does change to 64 bits with the above definitions.  "struct stat"
    uses off_t for storing file sizes.

P2. Assuming that a pointer to a 64-bit variable were to be passed to
    cli_qpathinfo2() for storing the file size, the size then needs to be
    parsed out completely.  The documentation (draft-leach-cifs-v1-spec-02)
    and the code do not match the current implementation.  The code is parsing
    the file size as four bytes at offset 48, but the documentation for
    SMB_QUERY_FILE_ALL_INFO indicates that the 8-byte EndofFile value should
    begin at offset 42.  Even assuming that the high-order four bytes are
    being ignored, I would expect to find the low-order four bytes at offset
    46, not offset 48.  The code has been working, however, for <4GB files, so
    it seems the documentation, not the code is in error.

I would like to make the following changes:

C1. Replace size_t with off_t in cli_qpathinfo() and cli_qpathinfo2() and the
    (very limited number of) places that call it.  This will effect torture.c,
    libsmbclient.c, clirap.c, and smbw_stat.c.  (In the latter case, I'll
    provide a local variable internally so the interface does not change.)

C2. If someone can provide a proper protocol definition for the response to
    a SMB_QUERY_FILE_ALL_INFO query, I will ensure that the the size is
    properly parsed from the PDU.  (Is there a protocol definition in ethereal
    someplace that would show the actual offsets of the fields in the
    response?)  Short of getting a protocol definition, I'll try to figure it
    out with ethereal, but it'd sure be easier if someone's already done
    that.

Thanks,    

Derrell