[Samba] libsmbclient help

[赵晶]

Thanks Jeremy, for this very detailed answer. I will discuss this
internally to my team first and get back to you if further questions.

Jeremy Allison <jra at samba.org> 于2021年1月14日周四 上午5:48写道：

> On Wed, Jan 13, 2021 at 08:06:23PM +0800, 赵晶 via samba wrote:
> >Hi Samba team,
> >
> >We're evaluating the use of libsmbclient API + smbclient utility
> >combination to back up a CIFS/SMB share from a Linux box. There are some
> >questions. Please help.
> >
> >1. There is no way to query Alternate Data Streams for a file in
> >libsmbclient. So we use smbclient 'allinfo'.
>
> Can you describe what API you'd like inside libsmbclient to
> return a list of ADS (Alternate Data Streams) ? We have
> the internal code to get this info, but don't currently
> export it.
>
> >*Is the output format of 'allinfo' guaranteed to be fixed (especially
> w.r.t
> >the three stream lines below)?* We need to parse the stream names out of
> >the allinfo result.
> >
> >smb: \> allinfo ads.txt
> >altname: ads.txt
> >create_time:    Mon Dec 14 08:32:07 AM 2020 EST
> >access_time:    Mon Dec 14 08:32:18 AM 2020 EST
> >write_time:     Mon Dec 14 08:33:22 AM 2020 EST
> >change_time:    Mon Dec 21 03:20:05 AM 2020 EST
> >attributes: A (20)
> >stream: [::$DATA], 3 bytes
> >stream: [:extra:$DATA], 8 bytes
> >stream: [:extra2:$DATA], 9 bytes
>
> Nothing in smbclient is "fixed" as an output format.
> It's not a standardized utility. Having said that
> we don't deliberately change or break things if
> we can help it.
>
> >2. We need to get security info (e.g, ACL, owner, groups, etc) of each
> >file/folder. Right now we query them using smbc_getxattr() and parse the
> >result. *Is the result format supposed to change (keywords as "OWNER:",
> >"GROUPS:", "ACL:")*?
> >
> >ACL info of smb://jingcs2.testlab.commvault.com/share/ads.txt:
>
> >REVISION:1,OWNER:S-1-5-32-544,GROUP:S-1-5-21-2539487108-1620125676-1447297442-513,ACL:S-1-5-21-2539487108-1620125676-1447297442-1010:1/16/0x001f01ff,ACL:S-1-5-18:0/16/0x001f01ff,ACL:S-1-5-21-2539487108-1620125676-1447297442-500:0/16/0x001f01ff,ACL:S-1-5-21-3393418607-3554941549-4209072599-1105:0/16/0x001f01ff,ACL:S-1-5-32-544:0/16/0x001f01ff,MODE:0x81e4,SIZE:3,A_TIME:1607952738,M_TIME:1607952802,C_TIME:1607952802,INODE:1143351355398743040
>
> As above.
>
> >3. *I don't find any API in libsmbclient to get reparse point info, e.g.,
> >to query allocation ranges for a sparse file. Is there a way to archive
> >this?*
>
> libsmbclient doesn't currently follow reparse points or
> get the info. That's something we'll probably be working
> on as part of the SMB2+UNIX extensions work as the plan
> is to expose server-symlinks as reparse points there so
> we'll need the code internally to support this.
>
> >   Right now smbc_read() gets the file as a complete non-sparse file (so
> is
> >smbclient's "get" command).
>
> We have internal code to do this, but again it's not
> exposed at the libsmbclient layer.
>
> >4. We include libsmbclient.h and links to libsmbclient.so. *Is it good
> >practice if we ship libsmbclient.so and its dependencies within our
> >products or use the ones shipped in the client environment? If the latter
> >case (don't ship ourselves), are the libsmbclient APIs (i.e., smbc_XXX)
> >guaranteed to be compatible across different Samba versions?* (e.g.,
> >older/newer versions of libsmbclient.so is installed on customer's
> clients,
> >will any API break?)
>
> Look at the major and minor version numbers of the library.
> Major version number changes can break the ABI, minor versions
> cannot.
>
> >5. *If we smbc_init() once and use different threads (which share the same
> >smb context) to access/download the same share (of course different
> >directories/files), is this supported in current model?*
>
> No, this will eventually cause problems. This code is not
> thread safe. Test using valgrind helgrind:
>
> https://www.valgrind.org/docs/manual/hg-manual.html
>
> to fixure out what you might be able to get away with
> if you're intent on doing this.
>
> It sounds to me you might be better using and extending
> the cli_XXX() internal layer of Samba and shipping your
> own version rather than depending on the shipped libraries.
>
> This cli_XXX() layer changes much more rapidly, but if
> you have your own version you can then track these
> changes with your own code.
>
> NOTE!!!! cli_XXX() is *NOT* a publicly supported ABI and we
> don't intend for it to be so, but if you want to
> build solutions on top of it you can always keep
> a local code branch.
>
> Also note the licensing - libsmbclient and cli_XXX
> are both GPLv3 - so consult your lawyers to understand
> your responsibilities here. Anything that links with
> them needs to be under a GPLv3-compatible license.
>
> I'm happy to work with you to look over and advise
> if you have code changes you'd like to get upstream
> into Samba to help it work better for your needs !
>
> Cheers,
>
> Jeremy.
>