[SCM] Samba Shared Repository - branch master updated -
Timur I. Bakeyev
timur at FreeBSD.org
Sun Feb 15 11:38:37 MST 2009
Why don't you use statfs() instead? The patch for it for ages in the FreeBSD
ports and in bugzilla, as I believe. It was promissed to be commited by ab
in 2005, but still is nowhere...
On Sun, Feb 15, 2009 at 12:09 AM, Tim Prouty <tprouty at samba.org> wrote:
> On Feb 14, 2009, at 7:48 AM, Derrell Lipman wrote:
> On Fri, Feb 13, 2009 at 4:00 PM, Tim Prouty <tprouty at samba.org> wrote:
>> s3 libsmbclient: Fix fstatvfs to be more portable
>>> The statvfs struct isn't guaranteed to be portable across operating
>>> systems. Since libsmbclient isn't actually calling statvfs and just
>>> using the statvfs struct to store similar information, this patch adds
>>> a new portable smbc_statvfs struct. This fixes a few of the failures
>>> in the build farm introduced by:
>>> Derrell, please check.
>> Hi Tim,
>> I changed this back to what I had originally, to see what was happening.
>> I've caught the errors you referenced in the Isilon FreeBSD server in the
>> build farm. It's indicating that you have a "struct statvfs" but that it
>> doesn't contain two of the fields we use. Would you please send me what
>> statvfs structure looks like. I see that configure already determines
>> whether the f_frsize field exists and I can check for that, but it doesn't
>> check whether the f_flag field exists. I suspect we need to add a check
>> that, and hopefully FreeBSD provides an equivalent field since that's the
>> key part of this new function.
> Hi Derrell,
> Thanks for digging into to this to figure out the best solution. I figured
> since you were using smbclient-specific flags, the semantic meaning of your
> statvfs struct was different from the posix description, and thus should be
> disambiguated with a different struct. I agree with your points though, and
> appreciate the patches you have pushed to help deal with the quirky statvfs
> implementation on our system. Unfortunately, the Isilon statvfs struct
> doesn't comply with the opengroup standard, as it was added to our kernel
> before FreeBSD had a statvfs implementation. I expect that we will fix this
> in the future to comply with the standard.
> The patches you pushed this afternoon pretty much nailed down the areas
> where we diverge. One request: would you be able to remove the #warnings?
> To help identify simple bugs, we build with --enable-picky-developer on by
> default which adds -Werror.
> Again, I really appreciate your diligence in getting this fixed the right
> way :)!
More information about the samba-technical