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

[Tim Prouty]

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