[SCM] Samba Shared Repository - branch master updated - release-4-0-0alpha6-868-g5e5d2b2

[Timur I. Bakeyev]

Hi, Derrell!

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...

Cheers,
Timur.

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:
>>>  ae259575c447e61665c8e7070c476914161b953f
>>>
>>>  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
>> your
>> 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
>> for
>> 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 :)!
>
> -Tim
>