Re: SmbFile.getDiskFreeSpace bug

Nice job Thomas. Not sure when I'll get a chance to integrate this though.
I'll put it in my patch queue...

Thanks,
Mike

Thomas Krammer said:
>
>> The Windows Explorer is reporting the correct value. Windows XP is
>> using information level 1007 instead of information level 1 which
>> JCIFS uses. According the the Samba sources this is
>>
>> #define SMB_FS_FULL_SIZE_INFORMATION            1007
>>
>> It returns the following information (see trans2.c in the Samba
>> sources):
>>
>> int64 Total allocation units
>> int64 Caller available allocation units
>> int64 Actual available allocation units
>> int32 Sectors per allocation unit
>> int32 Bytes per sector
>>
>> So it returns the block counts as 64 bit integers instead of 32 bit
>> integers.
>>
>> I extended getDiskFreeSpace() to use SMB_FS_FULL_SIZE_INFORMATION. If
>> the server returns a NT_STATUS_INVALID_INFO_CLASS error I fall back to
>> SMB_INFO_ALLOCATION. I don't know if there is a way to know if the
>> server supports a certain information level before making the call.
>>
>> I attached a patch with my extensions. I did some limited testing
>> against a Windows 2003 Server and it seems to work fine. I also asked
>> our customer to try out the patched JCIFS library. I will report back
>> as soon as I hear from them.
>>
> Of course it didn't work on their machine...
>
> I just copied the int64 handling from
> Trans2QueryFSInformationResponse.readSmbQueryFSSizeInfoWireFormat().
> That code doesn't work when actually more than 32 bit of the int64 are
> used.
>
> I'm now using readInt8() and it works fine. I also fixed
> readSmbQueryFSSizeInfoWireFormat(). I attached the fixed version of the
> patch.
>
>
>   Thomas
>
>