PGP SIGNED MESSAGE
Hash: SHA1
Kalim,
Pretty cool stuff :-)
$ bin/smbclient //queso/public -Ujerry%foo -W VALE
Workgroup: VALE
Username: jerry
Password:
smb: /dir
. error: Invalid argument
error: Invalid argument
admin drwxr-xr-x 0 Tue Jul 11 08:13:01 2000
hail error: Permission denied
bin32 drwxr-xr-x 0 Wed Mar 27 08:17:00 2002
sp6symic.exe -rw-r 39766496 Tue Jan 25 11:30:13 2005
sp6a dr-xr-xr-x 0 Tue Jan 25 12:26:19 2005
spoolss drwxr-xr-x 0 Mon Nov 10 10:02:50 2003
sp6a_checked dr-xr-xr-x 0 Tue Jan 25 11:53:39 2005
spud error: Permission denied
Makefile.in -r 59741 Wed Feb 23 07:26:21 2005
I checked client.c and there's still a good number of commands
commented out. Which ones do you think can be finished in time?
the [m]get and [m]put options are a requirement.
And I think cleaning up the error messages in the above output
is important. The two directories, 'hail' and 'spud' are msdfs
links btw And the extra prompt for a password should be
cleaned up (since the password was specified on the command line).
Do all of the posix commands, such as chmod and chown, have an
interface in libsmbclient?
As far as final deliverables go, we can't really swap out
the existing smbclient due to some changes in the display
mode or features that people may be relying on. So we should
probably include this as a new client. Got any ideas for
a name? We can eventually deprecate the existing smbclient
once all the current features are covered in the new code.
Same deal for final deliverable. I need a patch file against
the current SAMBA_3_0 tree (as of the last week of Aug I guess).
Make sure to include the necessary Makefile changes for the
new binary rather than changing the existing smbclient make
rules.
cheers, jerry
Alleviating the pain of Windows(tm) http://www.samba.org
GnuPG Key
"I never saved anything for the swim back." Ethan Hawk in Gattaca
PGP SIGNATURE
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
6WcG62WWdCTa7t03R8opIHc=
=mVUd
PGP SIGNATURE

PGP SIGNED MESSAGE
Hash: SHA1

David Collier-Brown wrote:
Gerald (Jerry) Carter wrote:
>As far as final deliverables go, we can't really swap out
>the existing smbclient due to some changes in the display
>mode or features that people may be relying on. So we should
>probably include this as a new client. Got any ideas for
>a name? We can eventually deprecate the existing smbclient
>once all the current features are covered in the new code.

If you started out using the same interfaces,
you might just make it libsmbclient.so.2 or maybe 1.1 (;-))

Dave, This is a new version on the smbclient tool.
Not a new version of libsmbclient.so.
And naming it smbclient2 or smbclient-ng seems so cliche. :-)

cheers, jerry
PGP SIGNATURE
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

PA5NCFL181XXSeMsQn0wFbk=
=9awC
PGP SIGNATURE

8/16/05, Gerald (Jerry) Carter <jerry (AT) samba (DOT) orgwrote:
PGP SIGNED MESSAGE
Hash: SHA1

Kalim,

Pretty cool stuff :-)

Thanks!

$ bin/smbclient //queso/public -Ujerry%foo -W VALE
Workgroup: VALE
Username: jerry
Password:
smb: /dir
. error: Invalid argument
error: Invalid argument
admin drwxr-xr-x 0 Tue Jul 11 08:13:01 2000
hail error: Permission denied
bin32 drwxr-xr-x 0 Wed Mar 27 08:17:00 2002
sp6symic.exe -rw-r 39766496 Tue Jan 25 11:30:13 2005
sp6a dr-xr-xr-x 0 Tue Jan 25 12:26:19 2005
spoolss drwxr-xr-x 0 Mon Nov 10 10:02:50 2003
sp6a_checked dr-xr-xr-x 0 Tue Jan 25 11:53:39 2005
spud error: Permission denied
Makefile.in -r 59741 Wed Feb 23 07:26:21 2005

I checked client.c and there's still a good number of commands
commented out. Which ones do you think can be finished in time?
the [m]get and [m]put options are a requirement.

Yup, '[m]get' and '[m]put' are definitely of primary importance.
those are done, 'more', 'reput', and 'reget' become trivial. I also
plan to get 'rm'/'del' done. Most of these will depend on the do_list
equivalent that I'm working on at the moment.

I'll try to get to the printing stuff before the deadline but I think
it's fair to say that's secondary to the commands I mentioned above
and might not be complete before Sep 1.

And I think cleaning up the error messages in the above output
is important. The two directories, 'hail' and 'spud' are msdfs
links btw And the extra prompt for a password should be
cleaned up (since the password was specified on the command line).

I'll get that password problem patched up. As for the dfs stuff, I
think I'm going to have to hack libsmbclient to get around the spotty
dfs support. I hadn't tested against dfs shares, but now that I look
at it, it's really behaving unexpectedly.

Those errors should be mostly cleaned up soon. The only way I could
get file information and maintain a healthy level of abstraction was
to use smbc_stat(). Unfortunately, that function won't handle locked
files (e.g. pagefile.sys) the way cli_list does, nor does it return
the same data (hence, the different output). It might be worthwhile to
add a new function to libsmbclient that wraps cli_list. Whaddya think?

Do all of the posix commands, such as chmod and chown, have an
interface in libsmbclient?

We may be missing a few but chown and chmod are there.

As far as final deliverables go, we can't really swap out
the existing smbclient due to some changes in the display
mode or features that people may be relying on. So we should
probably include this as a new client. Got any ideas for
a name? We can eventually deprecate the existing smbclient
once all the current features are covered in the new code.

Which reminds me that I wanted to let you know that I absolutely want
to continue developing this client after the pesky Google deadline is
out of the way :)
As for the name, I'm open to suggestions. smbclient2 does seem a bit
bland doesn't it? Anyone on the list want to throw something out
there?

Same deal for final deliverable. I need a patch file against
the current SAMBA_3_0 tree (as of the last week of Aug I guess).
Make sure to include the necessary Makefile changes for the
new binary rather than changing the existing smbclient make
rules.

Will do.

cheers, jerry

Alleviating the pain of Windows(tm) http://www.samba.org
GnuPG Key
"I never saved anything for the swim back." Ethan Hawk in Gattaca
PGP SIGNATURE
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

6WcG62WWdCTa7t03R8opIHc=
=mVUd
PGP SIGNATURE

Wednesday 17 August 2005 00:50, Kalim M wrote:
Which reminds me that I wanted to let you know that I absolutely want
to continue developing this client after the pesky Google deadline is
out of the way :)
As for the name, I'm open to suggestions. smbclient2 does seem a bit
bland doesn't it? Anyone on the list want to throw something out
there?

How about 'cifs-client' ?
- John T.

Kalim M <kmoghul (AT) gmail (DOT) comwrites:

Those errors should be mostly cleaned up soon. The only way I could
get file information and maintain a healthy level of abstraction was
to use smbc_stat(). Unfortunately, that function won't handle locked
files (e.g. pagefile.sys) the way cli_list does, nor does it return
the same data (hence, the different output). It might be worthwhile to
add a new function to libsmbclient that wraps cli_list. Whaddya think?

The current (samba3) libsmbclient provides PSIX-like functionality, at the
expense of flexibility and general access to the capabilities of the protocol.
If you saw my post a week or so ago about my goals for the samba4
libsmbclient, you'll note that in that one, I want to expose all low-level
capabilities, as well as having a backward-compatible module for the PSIX-
like interface.

If you can think of a PSIX-like function that cli_list() could be wrapped in
(or a way to implement one of the existing smbc_ functions using cli_list()
instead of what it's already using to provide additional capability), then
that would probably be worthwhile to implement. If cli_list() can not easily
map to a PSIX-like function, however, I'd like to leave this proposed
addition out of the samba3 libsmbclient so that we don't end up adding
unnecessary backward-compatibility requirements to the samba4 library.

Cheers,

Derrell
libsmbclient maintainer

PGP SIGNED MESSAGE
Hash: SHA1

Kalim M wrote:

>Yup, '[m]get' and '[m]put' are definitely of primary importance.
>those are done, 'more', 'reput', and 'reget' become trivial. I also
>plan to get 'rm'/'del' done. Most of these will depend on the do_list
>equivalent that I'm working on at the moment.

>I'll try to get to the printing stuff before the deadline
>but I think it's fair to say that's secondary to
>the commands I mentioned above and might not be complete
>before Sep 1.

The printing commands are secondary for this project IM
Bonus points and respect if you can get to this. :-)

>I'll get that password problem patched up. As for the
>dfs stuff, I think I'm going to have to hack libsmbclient
>to get around the spotty dfs support. I hadn't tested against
>dfs shares, but now that I look at it, it's really
>behaving unexpectedly.

I would really like to see the dfs stuff finished. It's
a pretty important features in current client tools
and people miss it when it's gone.

If you need to test against dfs servers, let me know and I
can give you access to my network. you can just setup a
Samba that refers back to itself.

>Those errors should be mostly cleaned up soon. The only
>way I could get file information and maintain a healthy
>level of abstraction was to use smbc_stat(). Unfortunately,
>that function won't handle locked files (e.g. pagefile.sys)
>the way cli_list does, nor does it return the same data (hence,
>the different output). It might be worthwhile to add a new
>function to libsmbclient that wraps cli_list. Whaddya think?

Hmmmok. I see what you mean. The libsmbclient design is
kind at odds with what we are trying to here isn't it.
I guess I always assumed there was a findfirst/findnext
interface in libsmbclient. Seems like smbc_opendir()
calls cli_list. Hmmmwhy doesn't that work?

As far as final deliverables go, we can't really swap out
the existing smbclient due to some changes in the display
mode or features that people may be relying on. So we should
probably include this as a new client. Got any ideas for
a name? We can eventually deprecate the existing smbclient
once all the current features are covered in the new code.

>Which reminds me that I wanted to let you know that I
>absolutely want to continue developing this client after
>the pesky Google deadline is out of the way :)

Excellent :-) I was hoping you'd say that. Let's get
past the google deadlines first and then we'll figure out
what comes next.

>As for the name, I'm open to suggestions. smbclient2 does
>seem a bit bland doesn't it? Anyone on the list want to
>throw something out there?

How about smbctool?

cheers, jerry

Alleviating the pain of Windows(tm) http://www.samba.org
GnuPG Key
"I never saved anything for the swim back." Ethan Hawk in Gattaca
PGP SIGNATURE
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

lDSCAlzgmYeRiVL62NPXnZ4=
=Ccwr
PGP SIGNATURE

PGP SIGNED MESSAGE
Hash: SHA1

derrell (AT) samba (DOT) org wrote:

If you can think of a PSIX-like function that cli_list()
could be wrapped in (or a way to implement one of the
existing smbc_ functions using cli_list() instead of
what it's already using to provide additional capability),
then that would probably be worthwhile to implement. If
cli_list() can not easily map to a PSIX-like function, however,
I'd like to leave this proposed addition out of the samba3
libsmbclient so that we don't end up adding
unnecessary backward-compatibility requirements to the
samba4 library.

Derrell,

I think we just need to flesh out the dir_list_fn() in
libsmbclient.c. cli_list() is already called by smbc_opendir_ctx()

cheers, jerry
PGP SIGNATURE
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

BC2F+khIm0Y/Tt7gh7MtEk=
=jyPL
PGP SIGNATURE

"Gerald (Jerry) Carter" <jerry (AT) samba (DOT) orgwrites:

derrell (AT) samba (DOT) org wrote:
>
>If you can think of a PSIX-like function that cli_list()
>could be wrapped in (or a way to implement one of the
>existing smbc_ functions using cli_list() instead of
>what it's already using to provide additional capability),
>then that would probably be worthwhile to implement. If
>cli_list() can not easily map to a PSIX-like function, however,
>I'd like to leave this proposed addition out of the samba3
>libsmbclient so that we don't end up adding
>unnecessary backward-compatibility requirements to the
>samba4 library.
>
Derrell,

I think we just need to flesh out the dir_list_fn() in
libsmbclient.c. cli_list() is already called by smbc_opendir_ctx()

Yes, I assumed that opendir() didn't or couldn't provide what Kalim was
looking for. Maybe that was a bad assumption.

What additional features, beyond what opendir() currently does, are required?
The question is whether they can be exposed in a reasonably clean way, without
affecting backward compatibility.

Cheers,

Derrell

8/17/05, Gerald (Jerry) Carter <jerry (AT) samba (DOT) orgwrote:
I would really like to see the dfs stuff finished. It's
a pretty important features in current client tools
and people miss it when it's gone.

If you need to test against dfs servers, let me know and I
can give you access to my network. you can just setup a
Samba that refers back to itself.

I have a machine running Win2k server with a standalone dfs root that
I have access to for the moment but I think I'm going to need
something else. A couple of dfs servers to test against would do the
trick.

>As for the name, I'm open to suggestions. smbclient2 does
>seem a bit bland doesn't it? Anyone on the list want to
>throw something out there?

How about smbctool?

Perfect. smbctool it is.
-Kalim

8/17/05, derrell (AT) samba (DOT) org <derrell (AT) samba (DOT) orgwrote:
"Gerald (Jerry) Carter" <jerry (AT) samba (DOT) orgwrites:

derrell (AT) samba (DOT) org wrote:
>
>If you can think of a PSIX-like function that cli_list()
>could be wrapped in (or a way to implement one of the
>existing smbc_ functions using cli_list() instead of
>what it's already using to provide additional capability),
>then that would probably be worthwhile to implement. If
>cli_list() can not easily map to a PSIX-like function, however,
>I'd like to leave this proposed addition out of the samba3
>libsmbclient so that we don't end up adding
>unnecessary backward-compatibility requirements to the
>samba4 library.
>
Derrell,

I think we just need to flesh out the dir_list_fn() in
libsmbclient.c. cli_list() is already called by smbc_opendir_ctx()

Yes, I assumed that opendir() didn't or couldn't provide what Kalim was
looking for. Maybe that was a bad assumption.

What additional features, beyond what opendir() currently does, are required?
The question is whether they can be exposed in a reasonably clean way, without
affecting backward compatibility.

Cheers,

Derrell

Hmmopendir does use cli_list() after all. The problem is that the
file_info struct isn't saved by dir_list_fn() and I don't see a way
to get to it through something like smbc_readdir(). I tried working
around that limitation using smbc_stat() which, when you get down to
it, uses qpathinfo (or SMBgetatr) which apparently isn't doing the
same job as when cli_list() uses findfirst/findnext.

I guess if dir_list_fn() can do a little more and save file_info that
would be ok. course, then we'll need a clean way to access that
data. Though, I really just want to be able to do something like pass
a more interesting function to cli_list() in place of dir_list_fn().
Not sure if there's a PSIX-happy way to do it but it would be nice.
-Kalim

Kalim M <kmoghul (AT) gmail (DOT) comwrites:

Hmmopendir does use cli_list() after all. The problem is that the
file_info struct isn't saved by dir_list_fn() and I don't see a way
to get to it through something like smbc_readdir(). I tried working
around that limitation using smbc_stat() which, when you get down to
it, uses qpathinfo (or SMBgetatr) which apparently isn't doing the
same job as when cli_list() uses findfirst/findnext.

I guess if dir_list_fn() can do a little more and save file_info that
would be ok. course, then we'll need a clean way to access that
data. Though, I really just want to be able to do something like pass
a more interesting function to cli_list() in place of dir_list_fn().
Not sure if there's a PSIX-happy way to do it but it would be nice.

Yeah, that's what I thought you wanted to do. I had thought for a while about
doing something like passing additional info from the file_info back to the
user during smbc_readdir() by formatting the returned "file name" with
embedded null chars, something like this:

filename.txt\0size=<size>\0otherparm=<value>\0\0\0

or

filename.txt\0size=<size>;otherparm=<value>;\0

but that's just way too kludgy for my taste.

If smbc_stat() is unable to get information that firstfirst/findnext is able
to retrieve, then I wonder how much slower it would be to implement
smbc_stat() in terms of firstfirst? We just need to be sure that all of the
existing info provided by qpathinfo is also available with whatever we replace
that by. Also, depending on the windows version being talked to, the times
(mtime, etc.) are formatted differently and IIRC, can differ in whether they
are GMT or localtime. We'd need to handle those differences in the return
value from findfirst as well (if they are, in fact different there too).

Derrell