Repro: From Windows XP, connect to a Samba 3.x server exporting a nearly
empty filesystem. Query the used space of the share's filesystem via
<right click->Properties. Observe that the used space is zero.
tcpdump confirms that the issue lies with the Trans2 -> QUERY_FS_INFO
response and not with the client.
It appears that Samba rounds down used space under certain
circumstances. On large filesystems (billions of blocks) used space
rounded down quite substantially: 32MB in our case. Smaller filesystems
will exhibit smaller rounding error and some will not exhibit rounding
issues at all.
I believe the problem lies with dfree.c:disk_norm(), called via
vfswrap_disk_free()->sys_disk_free()->disk_free(). Specifically, this
function scales dfree (disk free), dsize (total filesystem size) and
bsize (block size) such that they can be represented using sixteen bits
or less. This results in a loss of precision for large values. Such
behavior is particularly odd given that a QUERY_FS_INFO response will
renormalize these numbers again as needed to support lp_block_size(),
and that the on-the-wire representations are 32 bit and 64 bit
disk_norm() appears to be obsolete logic, or at least not appropriate
for Windows, as the function's stated purpose is to "normalise for DOS
It seems like the disk_norm() function is obsolete or used too broadly.
Can it safely be removed from the Trans2 QUERY_FS_INFO path?
Can you send in the ethereal trace, and also the debug level 10 log so I can
track and fix this please (I need to see how the rounding is screwing up).
Created attachment 946 [details]
Ok, try this. It short-circuits the normalization if it's a trans2
request not an old DOS request.
Can you confirm if this works for you ? If so I'll commit it.
Yes, this patch has successfully solved the bug.
ready to apply and close.
sorry for the same, cleaning up the database to prevent unecessary reopens of bugs.