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 quantities. 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 usage." 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). Thanks, Jeremy.
Created attachment 946 [details] Proposed patch. 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. Jeremy.
Yes, this patch has successfully solved the bug.
ready to apply and close.
Applied. Jeremy.
sorry for the same, cleaning up the database to prevent unecessary reopens of bugs.