Bug 1992 - Returning *bsize of 2048 from VFS disk_free() function not accepted
Summary: Returning *bsize of 2048 from VFS disk_free() function not accepted
Alias: None
Product: Samba 3.0
Classification: Unclassified
Component: File Services (show other bugs)
Version: 3.0.7
Hardware: x86 Linux
: P3 minor
Target Milestone: none
Assignee: Samba Bugzilla Account
QA Contact: Samba QA Contact
Depends on:
Reported: 2004-11-03 11:32 UTC by terryg
Modified: 2020-12-21 01:11 UTC (History)
0 users

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description terryg 2004-11-03 11:32:53 UTC
I'm implementing a VFS module with a disk_free() function. The real file
system has a block size of 2048. When the *bsize, *dfree, and *dsize values
are populated accordingly (using vfswrap_disk_free) Samba doesn't seem to
like it. A Linux client box that has mounted the SMB share gets back zeros
if it does a statfs() on the share. 

If I double the value of *bsize to 4096 and cut *dfree and *dsize in half
before returning from my disk_free() function then everything seems to work
Comment 1 Björn Jacke 2020-12-20 16:54:54 UTC
sorry for the delay, the samba-technical mailing list is a better place to ask such things.
Comment 2 terryg 2020-12-20 20:06:44 UTC
Sorry for the delay? Sixteen years, seriously?
Comment 3 Jeremy Allison 2020-12-21 00:28:15 UTC
Well remember Samba is staffed by volunteers, so unless you're paying for a support contract (something we highly recommend BTW :-) I don't think it's really too fair to complain when Björn is trying to tidy up our outstanding bug list.
Comment 4 terryg 2020-12-21 01:11:13 UTC
I was trying to help *you* out by reporting the bug, not myself. It seemed rather serious and I thought *you* might like to know about it. I must have found a way around it because I did end up completing the project I was working on at the time.

But after this much time, if you had just closed the bug report after not being able to replicate it, that would have been sufficient for ticket clean-up purposes. It would have been surprising indeed if the issue was reproducible after 16 years of code changes. Being redirected to the samba-technical mailing list after all this time just seems kind of silly.