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