client: browse doesn't work with only win98 in workgroup
It appears that name_resolve_bcast() does not find hosts in a workgroup if there are only win98 or win95 machines in the workgroup. The request sent to 192.168.1.255 receives no response. If there is a win2000 machine in the workgroup (and thus it is the master browser), a proper response is received to the request sent to 192.168.1.255. Here's a trace with only a win98 machine in the workgroup, showing the lack of response. I would greatly appreciate hearing how to browse for servers in a workgroup with only win98 or win95 machines in the workgroup! In this trace, the workgroup in question is LIPMAN. Although I'm doing this with smbsh, client debugging is enabled and the calls to name_resolve_bcast() are shown... -- smbsh$ smbsh -n -d 9 smbw_path(.) cleaning /fiona/home/derrell/samba-2.2.7.sandbox-djl/source/bin/. smbw_path(.) cleaning /fiona/home/derrell/samba-2.2.7.sandbox-djl/source/bin/. smbw_path(./smbsh) cleaning /fiona/home/derrell/samba-2.2.7.sandbox-djl/source/bin/./smbsh cleaning /fiona/home/derrell/samba-2.2.7.sandbox-djl/source/bin/smbsh smbw_path(./smbsh) cleaning /fiona/home/derrell/samba-2.2.7.sandbox-djl/source/bin/./smbsh cleaning /fiona/home/derrell/samba-2.2.7.sandbox-djl/source/bin/smbsh fcntl_lock 8191 14 0 1 1 fcntl_lock: Lock call successful fcntl_lock 8191 13 0 1 2 fcntl_lock: Lock call successful fcntl_lock 8191 14 0 1 1 fcntl_lock: Lock call successful fcntl_lock 8191 13 0 1 2 fcntl_lock: Lock call successful fcntl_lock 8191 14 0 1 1 fcntl_lock: Lock call successful fcntl_lock 8191 13 0 1 2 fcntl_lock: Lock call successful fcntl_lock 8191 14 0 1 1 fcntl_lock: Lock call successful fcntl_lock 8191 13 0 1 2 fcntl_lock: Lock call successful fcntl_lock 8191 14 0 1 1 fcntl_lock: Lock call successful fcntl_lock 8191 13 0 1 2 fcntl_lock: Lock call successful Initial cwd is /fiona/home/derrell/samba-2.2.7.sandbox-djl/source/bin [2003/02/26 09:31:39, 8] lib/util.c:fcntl_lock(1304) fcntl_lock 8191 14 0 1 1 [2003/02/26 09:31:39, 8] lib/util.c:fcntl_lock(1342) fcntl_lock: Lock call successful [2003/02/26 09:31:39, 8] lib/util.c:fcntl_lock(1304) fcntl_lock 8191 13 0 1 2 [2003/02/26 09:31:39, 8] lib/util.c:fcntl_lock(1342) fcntl_lock: Lock call successful [2003/02/26 09:31:39, 8] lib/util.c:fcntl_lock(1304) fcntl_lock 8191 14 0 1 1 [2003/02/26 09:31:39, 8] lib/util.c:fcntl_lock(1342) fcntl_lock: Lock call successful [2003/02/26 09:31:39, 8] lib/util.c:fcntl_lock(1304) fcntl_lock 8191 13 0 1 2 [2003/02/26 09:31:39, 8] lib/util.c:fcntl_lock(1342) fcntl_lock: Lock call successful fcntl_lock 8191 14 0 1 1 fcntl_lock: Lock call successful fcntl_lock 8191 13 0 1 2 fcntl_lock: Lock call successful fcntl_lock 8191 14 0 1 1 fcntl_lock: Lock call successful fcntl_lock 8191 13 0 1 2 fcntl_lock: Lock call successful fcntl_lock 8191 14 0 1 1 fcntl_lock: Lock call successful fcntl_lock 8191 13 0 1 2 fcntl_lock: Lock call successful Initial cwd is /fiona/home/derrell/samba-2.2.7.sandbox-djl/source/bin smbw_path(.) cleaning /fiona/home/derrell/samba-2.2.7.sandbox-djl/source/bin/. smbw_path(.) cleaning /fiona/home/derrell/samba-2.2.7.sandbox-djl/source/bin/. smbw_path(.) cleaning /fiona/home/derrell/samba-2.2.7.sandbox-djl/source/bin/. smbw_path(./smbsh) cleaning /fiona/home/derrell/samba-2.2.7.sandbox-djl/source/bin/./smbsh cleaning /fiona/home/derrell/samba-2.2.7.sandbox-djl/source/bin/smbsh smbw_path(./smbsh) cleaning /fiona/home/derrell/samba-2.2.7.sandbox-djl/source/bin/./smbsh cleaning /fiona/home/derrell/samba-2.2.7.sandbox-djl/source/bin/smbsh smbsh$ ls /smb/LIPMAN smbw_path(.) cleaning /fiona/home/derrell/samba-2.2.7.sandbox-djl/source/bin/. smbw_path(.) cleaning /fiona/home/derrell/samba-2.2.7.sandbox-djl/source/bin/. smbw_path(./ls) cleaning /fiona/home/derrell/samba-2.2.7.sandbox-djl/source/bin/./ls cleaning /fiona/home/derrell/samba-2.2.7.sandbox-djl/source/bin/ls fcntl_lock 8191 14 0 1 1 fcntl_lock: Lock call successful fcntl_lock 8191 13 0 1 2 fcntl_lock: Lock call successful fcntl_lock 8191 14 0 1 1 fcntl_lock: Lock call successful fcntl_lock 8191 13 0 1 2 fcntl_lock: Lock call successful fcntl_lock 8191 14 0 1 1 fcntl_lock: Lock call successful fcntl_lock 8191 13 0 1 2 fcntl_lock: Lock call successful fcntl_lock 8191 14 0 1 1 fcntl_lock: Lock call successful fcntl_lock 8191 13 0 1 2 fcntl_lock: Lock call successful fcntl_lock 8191 14 0 1 1 fcntl_lock: Lock call successful fcntl_lock 8191 13 0 1 2 fcntl_lock: Lock call successful Initial cwd is /fiona/home/derrell/samba-2.2.7.sandbox-djl/source/bin smbw_path(/smb/LIPMAN) cleaning /smb/LIPMAN stat(/smb/LIPMAN) cleaning /smb/LIPMAN fcntl_lock 8191 14 0 1 1 fcntl_lock: Lock call successful fcntl_lock 8191 13 0 1 2 fcntl_lock: Lock call successful fcntl_lock 8191 14 0 1 1 fcntl_lock: Lock call successful fcntl_lock 8191 13 0 1 2 fcntl_lock: Lock call successful fcntl_lock 8191 14 0 1 1 fcntl_lock: Lock call successful fcntl_lock 8191 13 0 1 2 fcntl_lo
Re: client: browse doesn't work with only win98 in workgroup
Previously I wrote: > It appears that name_resolve_bcast() does not find hosts in a workgroup if > there are only win98 or win95 machines in the workgroup. The method that's being used for browsing, where a cli_session_request() is sent to the master browser, does not work if the master browser is a win98 machine. The win98 machine returns 0x83 (NEGATIVE SESSION RESPONSE). It does work if the master browser is a win2000 machine, which returns 0x82 (POSITIVE SESSION RESPONSE). What is the proper procedure for browsing for hosts in a workgroup if the master browser for the workgroup is a win98 machine? I can brute-force it with "nmblookup -r -S " which issues node status and various things. Is that really the way to do it, and if so, is there a reason that the smbwrapper code doesn't use that method rather than the cli_session_request() method? Thanks, Derrell
Re: client: browse doesn't work with only win98 in workgroup
I am interested in looking into this, but I won't have time until the weekend. Chris -)- On Thu, Feb 27, 2003 at 02:51:55PM -0500, [EMAIL PROTECTED] wrote: > Previously I wrote: > > > It appears that name_resolve_bcast() does not find hosts in a workgroup if > > there are only win98 or win95 machines in the workgroup. > > The method that's being used for browsing, where a cli_session_request() is > sent to the master browser, does not work if the master browser is a win98 > machine. The win98 machine returns 0x83 (NEGATIVE SESSION RESPONSE). It does > work if the master browser is a win2000 machine, which returns 0x82 (POSITIVE > SESSION RESPONSE). > > What is the proper procedure for browsing for hosts in a workgroup if the > master browser for the workgroup is a win98 machine? I can brute-force it > with "nmblookup -r -S " which issues node status and various > things. Is that really the way to do it, and if so, is there a reason that > the smbwrapper code doesn't use that method rather than the > cli_session_request() method? > > Thanks, > > Derrell -- Samba Team -- http://www.samba.org/ -)- Christopher R. Hertel jCIFS Team -- http://jcifs.samba.org/ -)- ubiqx development, uninq. ubiqx Team -- http://www.ubiqx.org/ -)- [EMAIL PROTECTED] OnLineBook -- http://ubiqx.org/cifs/-)- [EMAIL PROTECTED]
Re: client: browse doesn't work with only win98 in workgroup
"Christopher R. Hertel" <[EMAIL PROTECTED]> writes:
> I am interested in looking into this, but I won't have time until the
> weekend.
Great. Thanks for the response!
In the mean time, I have modified smbw_dir.c to include a new function
smbw_browse_workgroup_alternate() with the following patch. The code is
basically stolen from nmblookup.c.
Since there is now some duplicated code pertaining to allocating and
initializing the smbw_dir structure, I also created a function to do that,
which is called from a couple of places.
This modification affects only the opendir()/readdir() functionality. I think
that it does not solve the problem in the more generic case. From smbsh, "ls
/smb/WORKGROUP" still fails although my test program (attached at bottom)
which uses opendir() and readdir() now succeeds. I haven't looked at the 'ls'
source code, but I suspect that it is doing stat() calls after the readdir,
and that is failing.
--
diff -u samba-2.2.7.sandbox-orig/source/smbwrapper/smbw_dir.c
samba-2.2.7.sandbox-test/source/smbwrapper/smbw_dir.c
--- samba-2.2.7.sandbox-orig/source/smbwrapper/smbw_dir.c Wed Jan 29 11:24:58
2003
+++ samba-2.2.7.sandbox-test/source/smbwrapper/smbw_dir.c Fri Feb 28 11:57:01
2003
@@ -27,9 +27,10 @@
extern struct bitmap *smbw_file_bmap;
extern int smbw_busy;
-static struct smbw_dir *smbw_dirs;
+static struct smbw_dir *smbw_dirs = NULL;
static int ServerFD= -1;
+static void *smbw_browse_workgroup_alternate(char *path, char *workgroup);
/*
map a fd to a smbw_dir structure
@@ -72,6 +73,11 @@
SAFE_FREE(dir);
}
+void smbw_free_dir(void *dir)
+{
+free_dir((struct smbw_dir *) dir);
+}
+
static struct smbw_dir *cur_dir;
@@ -113,8 +119,8 @@
/*
add a entry to a directory listing
***/
-static void smbw_share_add(const char *share, uint32 type,
- const char *comment, void *state)
+void smbw_share_add(const char *share, uint32 type,
+const char *comment, void *state)
{
struct smbw_file_info finfo;
@@ -157,8 +163,8 @@
/*
add a server to a directory listing
***/
-static void smbw_server_add(const char *name, uint32 type,
- const char *comment, void *state)
+void smbw_server_add(const char *name, uint32 type,
+ const char *comment, void *state)
{
int count;
struct smbw_file_info finfo;
@@ -195,6 +201,31 @@
}
+
+/**
+allocate an smbw_dir structure and initialize it.
+***/
+void *smbw_dir_alloc(struct smbw_server *srv, int fd, char *path)
+{
+struct smbw_dir *dir;
+
+ dir = (struct smbw_dir *)malloc(sizeof(*dir));
+ if (!dir)
+return NULL;
+
+ ZERO_STRUCTP(dir);
+
+dir->srv = srv;
+dir->fd = fd;
+dir->path = (path == NULL ? NULL : strdup(path));
+bitmap_set(smbw_file_bmap, fd);
+
+ cur_dir = dir;
+
+return dir;
+}
+
+
/*
open a directory on the server
***/
@@ -223,22 +254,24 @@
/* get a connection to the server */
srv = smbw_server(server, share);
if (!srv) {
- /* smbw_server sets errno */
- goto failed;
+ /* smbw_server sets errno. try alt method if workgroup */
+if ((p=strstr(server,"#1D"))) {
+DEBUG(4, ("dir_open workgroup: trying alternate method"));
+*p = '\0';
+if (p > server && p[-1] == ':')
+p[-1] = '\0';
+if ((dir = smbw_browse_workgroup_alternate((char *) fname,
server)))
+return dir->fd;
+}
+goto failed;
}
- dir = (struct smbw_dir *)malloc(sizeof(*dir));
+ dir = smbw_dir_alloc(srv, 0, NULL);
if (!dir) {
errno = ENOMEM;
goto failed;
}
- ZERO_STRUCTP(dir);
-
- cur_dir = dir;
-
- dir->srv = srv;
-
slprintf(mask, sizeof(mask)-1, "%s\\*", path);
all_string_sub(mask,"","\\",0);
@@ -772,3 +805,74 @@
return smbw_dir_lseek(d->fd,0,SEEK_CUR);
}
+
+
+/*
+ * smbw_browse_workgroup_alternate()
+ *
+ * The normal smbwrapper method of browsing for host names doesn't work if the
+ * master browser for the workgroup is a Windows 98 or Windows 95 system.
+ * This function tries a different method of
Re: client: browse doesn't work with only win98 in workgroup
[EMAIL PROTECTED] writes: > "Christopher R. Hertel" <[EMAIL PROTECTED]> writes: > >> I am interested in looking into this, but I won't have time until the >> weekend. > > ... > > In the mean time, I have modified smbw_dir.c to include a new function > smbw_browse_workgroup_alternate() with the following patch. The code is > basically stolen from nmblookup.c. More testing (and the "Duh!" factor upon reviewing the code) reveals that the code I added does not find all hosts in a workgroup; it finds "some" of the hosts. Actually, it finds _one_ host each time it's run, not necessarily the same host each time. I'll have to work on this some more if the cli_session_request() method can't be made to work properly with win98 and win95 machines as master browsers. Derrell
Re: client: browse doesn't work with only win98 in workgroup
[EMAIL PROTECTED] wrote: > > [EMAIL PROTECTED] writes: > > > "Christopher R. Hertel" <[EMAIL PROTECTED]> writes: > > > >> I am interested in looking into this, but I won't have time until the > >> weekend. > > > > ... > > > > In the mean time, I have modified smbw_dir.c to include a new function > > smbw_browse_workgroup_alternate() with the following patch. The code > > is basically stolen from nmblookup.c. > > More testing (and the "Duh!" factor upon reviewing the code) reveals > that the code I added does not find all hosts in a workgroup; it finds > "some" of the hosts. Actually, it finds _one_ host each time it's run, > not necessarily the same host each time. I'll have to work on this some > more if the cli_session_request() method can't be made to work properly > with win98 and win95 machines as master browsers. Derrell, Can you give me a better idea of what you are trying to do? Above, you say you are trying to find all hosts that are members of a given workgroup. The question is: why? What is it that you are actually trying to accomplish? Keep in mind that there is a *very* big difference between the set of hosts that are members of a workgroup and the set of servers offering services within that workgroup. Two distinct systems are used to gather those two lists. Chris -)- -- Samba Team -- http://www.samba.org/ -)- Christopher R. Hertel jCIFS Team -- http://jcifs.samba.org/ -)- ubiqx development, uninq. ubiqx Team -- http://www.ubiqx.org/ -)- [EMAIL PROTECTED] OnLineBook -- http://ubiqx.org/cifs/-)- [EMAIL PROTECTED]
Re: client: browse doesn't work with only win98 in workgroup
"Christopher R. Hertel" <[EMAIL PROTECTED]> writes: > Derrell, > > Can you give me a better idea of what you are trying to do? > > Above, you say you are trying to find all hosts that are members of a given > workgroup. The question is: why? What is it that you are actually trying > to accomplish? I'm working on providing a tree-style view of the network in a fashion similar to what Windows Explorer does. The top level of an SMB/CIFS network is something like "Microsoft Windows Network". The next level down is the list of workgroups/domains within the network; then the hosts within each workgroup; then the shares within each share, etc. I don't know what version of Windows will be the master browser, and I don't want to force it by using Samba as the master browser. Therefore I have to be able to enumerate the hosts within a workgroup regardless of what versions of Windows happen to be on the network. > Keep in mind that there is a *very* big difference between the set of hosts > that are members of a workgroup and the set of servers offering services > within that workgroup. Two distinct systems are used to gather those two > lists. The latter works fine. If I already know the host name, I can see the shares on that host. The problem is enumerating the hosts within a workgroup. In the case of smbwrapper and smbsh, one is supposed to be able to do: ls /smb to see the list of workgroups/domains, and ls /smb/WORKGROUP to see the list of hosts within the workgroup "WORKGROUP", and ls /smb/WORKGROUP/HOST to see a list of shares on the computer called "HOST". All of these work with the method implemented in smbwrapper, except for enumerating the list of hosts within a workgroup where the master browser for the workgroup is a Windows 98 or Windows 95 machine. If there is a Windows 2000 server acting as the master browser for the workgroup, then obtaining the list of hosts within the workgroup works fine. However, the cli_session_request() call fails (gets a result of 0x83 from the peer) when the master browser is a win98 machine, so the list of hosts within the workgroup is therefore unavailable. Does this help clarify the problem? If not, please query me again and I'll try to explain differently. Thanks for your help! Derrell
Re: client: browse doesn't work with only win98 in workgroup
On Sat, 1 Mar 2003 [EMAIL PROTECTED] wrote: > "Christopher R. Hertel" <[EMAIL PROTECTED]> writes: > > I'm working on providing a tree-style view of the network in a fashion similar > to what Windows Explorer does. The top level of an SMB/CIFS network is > something like "Microsoft Windows Network". The next level down is the list > of workgroups/domains within the network; then the hosts within each > workgroup; then the shares within each share, etc. I don't know what version > of Windows will be the master browser, and I don't want to force it by using > Samba as the master browser. Therefore I have to be able to enumerate the > hosts within a workgroup regardless of what versions of Windows happen to be > on the network. Hmmm, are you using libsmbclient? Regards - Richard Sharpe, rsharpe[at]ns.aus.com, rsharpe[at]samba.org, sharpe[at]ethereal.com, http://www.richardsharpe.com
Re: client: browse doesn't work with only win98 in workgroup
Okay, I understand the problem now. The problem is that W/9x boxes do not recognize the generic "*SMBSERVER" name in the NBT Session Setup Request. Also, W/9x boxes will send back an error if the called name is not correct in the NBT Session Setup Request. You should get a NEGATIVE SESSION RESPONSE (0x83) message with an error code of: 0x82: Called Name Not Present Since W/9x systems do not support the generic "*SMBSERVER" name, this error message is correct. Basically, it's the NBT equivalent of "That port isn't listening for a connection". The solution is to find the Server Service name on the remote machine. This is typically done by sending a Node Status query and looking for a name with a suffix byte value of 0x20. More inline below... [EMAIL PROTECTED] wrote: > > "Christopher R. Hertel" <[EMAIL PROTECTED]> writes: > > > Derrell, > > > > Can you give me a better idea of what you are trying to do? > > > > Above, you say you are trying to find all hosts that are members of a > > given workgroup. The question is: why? What is it that you are > > actually trying to accomplish? > > I'm working on providing a tree-style view of the network in a fashion > similar to what Windows Explorer does. The top level of an SMB/CIFS > network is something like "Microsoft Windows Network". The next level > down is the list of workgroups/domains within the network; Okay. At this level what you need to do is talk to *a\ny* Local Master Browser on the local LAN. If you know a specific workgroup name you can use that, otherwise you can find a list of workgroups by querying for the "\x01\x02__MSBROWSE__\x02<01>" name. (That last <01> is the suffix byte, value 0x01). If the network is relatively stable, the LMBs will have exchanged data with one another, and any LMB will have the list of all other workgroups that are known. Anyway, once you have one (or more) LMB IP addresses, you can try to query for the Browse List. In this case, you want only the workgroup/domain entries, so what you should see on the wire is a NetServerEnum2 Domain Enum request. > then the hosts within each workgroup; Nope. You can only get the list of servers in the workgroup that are advertising services. The list of all hosts which are workgroup members is not kept by the browse service. ...but that's not what you really want, anyway. What you really want is the list of known servers. That's a NetServerEnum2 with all the server type bits turned on. The LMB (or any available backup browser) should have this list. > then the shares within each share, etc. Shares offered by the server. Okay. Note that some servers require authentication before they allow enumeration of shares. > I don't know what version of Windows will be the master browser, and I > don't want to force it by using Samba as the master browser. Right. > Therefore I have to be able to enumerate the hosts within a workgroup > regardless of what versions of Windows happen to be on the network. That's not a problem, as long as you have a valid CALLED name in the NBT Session Request. Samba ignores the CALLED name, W/NT and W2K accept the generic "*SMBSERVER" name (so Samba can 'guess'), and I don't know about W/XP. W/9x, as you've seen, requires the correct name in this field. > > Keep in mind that there is a *very* big difference between the set of > > hosts that are members of a workgroup and the set of servers offering > > services within that workgroup. Two distinct systems are used to > > gather those two lists. > > The latter works fine. If I already know the host name, I can see the > shares on that host. No. That's not what I said. The "latter" in my note above is the "set of servers offering services within a workgroup" which is exactly what you're having trouble finding. > The problem is enumerating the hosts within a workgroup. I know that this is pedantic, but it's important to understand that there is a difference between the set of hosts in a workgroup and the servers offering SMB services in the workgroup. A host may be a client and it may not be offering SMB services, in which case it will not show up when you try listing the servers in the workgroup. > In the case of smbwrapper and smbsh, one is supposed to be able to do: > > ls /smb > > to see the list of workgroups/domains, and > > ls /smb/WORKGROUP > > to see the list of hosts within the workgroup "WORKGROUP", and ...all of the servers in the workgroup... > ls /smb/WORKGROUP/HOST > > to see a list of shares on the computer called "HOST". Right. We leverage that hierarchy with the SMB URL. See: http://www.ietf.org/internet-drafts/draft-crhertel-smb-url-04.txt > All of these work with the method implemented in smbwrapper, except for > enumerating the list of hosts within a workgroup where the master browser > for the workgroup is a Windows 98 or Windows 95 machine. Ah! Okay. As Richard asked... What tool are you using (libsmbclient?) to do this? It may
Re: client: browse doesn't work with only win98 in workgroup
On Sat, 1 Mar 2003, Christopher R. Hertel wrote: > Okay, I understand the problem now. > > The problem is that W/9x boxes do not recognize the generic "*SMBSERVER" > name in the NBT Session Setup Request. Also, W/9x boxes will send back an > error if the called name is not correct in the NBT Session Setup Request. > You should get a NEGATIVE SESSION RESPONSE (0x83) message with an error code > of: > 0x82: Called Name Not Present > > Since W/9x systems do not support the generic "*SMBSERVER" name, this error > message is correct. Basically, it's the NBT equivalent of "That port isn't > listening for a connection". > > The solution is to find the Server Service name on the remote machine. > This is typically done by sending a Node Status query and looking for a name > with a suffix byte value of 0x20. There is code in libsmbclient to deal with this problem ... Regards - Richard Sharpe, rsharpe[at]ns.aus.com, rsharpe[at]samba.org, sharpe[at]ethereal.com, http://www.richardsharpe.com
Re: client: browse doesn't work with only win98 in workgroup
"Christopher R. Hertel" <[EMAIL PROTECTED]> writes: > The problem is that W/9x boxes do not recognize the generic "*SMBSERVER" > name in the NBT Session Setup Request. Also, W/9x boxes will send back an > error if the called name is not correct in the NBT Session Setup Request. > You should get a NEGATIVE SESSION RESPONSE (0x83) message with an error code > of: > 0x82: Called Name Not Present > > Since W/9x systems do not support the generic "*SMBSERVER" name, this error > message is correct. Basically, it's the NBT equivalent of "That port isn't > listening for a connection". > > The solution is to find the Server Service name on the remote machine. > This is typically done by sending a Node Status query and looking for a name > with a suffix byte value of 0x20. Great! The information you provided here and interspersed in my message seems to be exactly what I needed. I should be able to implement this correctly now. > I know that this is pedantic, but it's important to understand that there is > a difference between the set of hosts in a workgroup and the servers > offering SMB services in the workgroup. A host may be a client and it may > not be offering SMB services, in which case it will not show up when you try > listing the servers in the workgroup. I know enough right now to ask intelligible questions, although not yet with correct terminology. I appreciate you setting me straight. Your explanation of not only the correct terminology, but why the terminology I was using actually had a different meaning, was enlightening. Thanks for your help! Derrell
Re: client: browse doesn't work with only win98 in workgroup
On Mon, Mar 03, 2003 at 09:41:51AM -0500, [EMAIL PROTECTED] wrote: : > I know enough right now to ask intelligible questions, although not yet with > correct terminology. I appreciate you setting me straight. Your explanation > of not only the correct terminology, but why the terminology I was using > actually had a different meaning, was enlightening. Most welcome. As it happens, I am currently working on writing the Browsing section of my online book, so the stuff is fairly fresh in my mind. :) Chris -)- -- Samba Team -- http://www.samba.org/ -)- Christopher R. Hertel jCIFS Team -- http://jcifs.samba.org/ -)- ubiqx development, uninq. ubiqx Team -- http://www.ubiqx.org/ -)- [EMAIL PROTECTED] OnLineBook -- http://ubiqx.org/cifs/-)- [EMAIL PROTECTED]
