Displaying 4 results from an estimated 4 matches for "do_list_help".
Did you mean:
do_list_helper
2007 Dec 17
1
problem with samba 3.0.28/Solaris 8/smbclient
Dear Samba users,
I am trying to update our local samba packages to 3.0.28.
They are built against heimdal-1.0.1 and openldap-2.3.38.
The Redhat Enterprise Linux 3 and 4 packages are working
fine so far in my limited testing. The problem with heimdal
and "net ads join..." has been fixed on all 3 platforms.
On the Solaris 8 server, the "net ads join..." works
correctly and the
2020 Aug 24
0
smbclient mask command seems not to work the same way with recurse ON for mget and mput
...Note, all it's doing is a mask_match() call against the
returned name and the string set via the 'mask' parameter.
Note that when you're doing 'recurse' and the operation
you set you're providing a second mask parameter '*'
in this case.
Looks like the function do_list_helper() only looks
at the mask set via the 'mask' command if it's not
recursing.
Looks like this might be a bug that no one ever ran
into before. Normally, people expect the mask given
to the mXXXX functions to take priority. I'm guessing
almost no one uses the 'mask' command.
2020 Aug 24
2
smbclient mask command seems not to work the same way with recurse ON for mget and mput
Dear fellows.
Another piece of information. The issue reprduces on RHEL 7.7, Samba 4.9.1
[root at vnhprerhds01 ~]# cat /etc/redhat-release
Red Hat Enterprise Linux Server release 7.7 (Maipo)
[root at vnhprerhds01 ~]# smbclient -V
Version 4.9.1
[root at vnhprerhds01 ~]# smbclient -W "${d}" -U "${u}" "${s}" "${p}"
Try "help" to get a list of
2020 Aug 24
2
smbclient mask command seems not to work the same way with recurse ON for mget and mput
...k_match() call against the
> returned name and the string set via the 'mask' parameter.
>
> Note that when you're doing 'recurse' and the operation
> you set you're providing a second mask parameter '*'
> in this case.
>
> Looks like the function do_list_helper() only looks
> at the mask set via the 'mask' command if it's not
> recursing.
>
> Looks like this might be a bug that no one ever ran
> into before. Normally, people expect the mask given
> to the mXXXX functions to take priority. I'm guessing
> almost no one...