Get Samba version or capability information from Windows

[George Colley]

  I have been asking for something like this for a long time, without  
much luck. In my case I just want a number that is incremented for  
each release. A version number would be fine. Strings are a pain in  
the ass for me, but even that would be ok. I would like the number to  
represent official Samba releases, not vendor releases. I know what  
Samba is doing in each release and what they fix. If vendors are  
changing this number then it really is not worth much to me.


Just my two cents worth,
George



On Jan 18, 2008, at 7:18 AM, Corinna Vinschen wrote:

> On Jan 18 16:12, Volker Lendecke wrote:
>> On Fri, Jan 18, 2008 at 09:04:09AM -0600, Gerald (Jerry) Carter  
>> wrote:
>>> Vendors are asked to moify the Vendor tag suffix in the
>>> VERSION file.  So smbd -V should tell you if you have upstream
>>> or if you have a vendor version.  If not, then we need to
>>> push back at the vendor in question.
>>>
>>> I could put the tag hash in the release notes but I doubt it
>>> is really all that helpful since in order to make any use of it
>>> you have to know how to use git.  And at that point, you really
>>> just want the tag name anyways.
>>>
>>> Hope I understood the question.
>>
>> The discussion was about how to encode the specific Samba
>> version in the SMB_FS_OBJECTID_INFORMATION qfsinfo reply
>> that we give. The point is that this information is
>> available in Win32 user space, Cygwin apparently could make
>> very good use of it to work around specific Samba
>> bugs/features/etc. Dave CB suggested to add 64 bits of the
>> git commit into the reply which would make the reply very
>> specific. I'm just the moderator here, Corrina seems to like
>
> s/rrin/rinn/
>
>> this idea.
>
> Oops, no, not really.  If you think it's useful, it's defintely fine
> with me, but afaics, I could live without this detail.  I don't think
> it's really a big loss if the support of intermediate (non-officially
> released) versions is a bit bumpy...
>
>> this idea. My personal opinion is that the version string
>> would be enough, but if there is an easy way to get the git
>> commit id into that reply, I'd not block that.
>
> ACK.  I guess it would be a good start if I implement this with just  
> the
> version number and string, and leave git commit tag support for some
> later date.
>
>
> Corinna