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

Jeremy Allison jra at samba.org
Wed Mar 16 01:50:28 GMT 2005


On Tue, Mar 15, 2005 at 08:46:08PM -0500, Derrell.Lipman at UnwiredUniverse.com wrote:
> 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.

Yes, this is completely correct. File sizes inside the Samba server are
expressed as SMB_OFF_T values (64 bit).

Using size_t in such an interface is broken.

> 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.

That's not a suprise :-). Look at the server code in smbd/trans2.c to see
how to encode it correctly.

> 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.)

Sounds good.

> 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.

As I said - check the server code in smbd/trans2.c for encoding SMB_QUERY_FILE_ALL_INFO.
That's definately correct.

Jeremy.



More information about the samba-technical mailing list