[jcifs] CIFS archives -- September 2001, week 2 (#14)
Christopher R. Hertel
crh at nts.umn.edu
Fri Sep 14 07:39:54 EST 2001
> The issue that we at Thursby have with the URL types is that our users
> need a single type allowing our implementation to locate computers,
That is the goal you have stated. I do not believe that it is "needed",
but I can see that it may be desirable.
> shares, files and folders regardless of how the infrastructure is set
> up (ie: NBT or 445, and independent of browsing technology).
You have listed computers (servers), shares, files, and folders. That
brings up the tough point: Shares, files, and folders are all basic SMB
and, as was discussed at the conference, there is one exchange within
the protocol that "goes away" under port 445 semantics. I still have
not had anyone explain to me how a client would go about searching for
the service list in this scenario. Given the string
I need to figure out if 'name' is a NetBIOS name or a DNS name. If it's
a NetBIOS name I need to figure out if it represents an SMB server or a
workgroup (or, in unusual cases, both). I know how to do that.
If, however, the name is a DNS name then I need to figure out if it is:
- an SMB over NBT server
- an SMB over native TCP server
- a W2K Domain Controller.
In that last case, I also need some idea how to read the browse list.
> For example, our customers need a way to access a particular folder
> on a particular server when they know the name of the computer and
> folder. This is in fact how Windows 2000 works when the file:// url
> form is used.
The case of file access is not at issue here. We concluded that it
could easily be done while at the conference.
> there any ambiguity when a user types in file://george/share_aaa on a
> Windows machine? Don't we all know what the user means?
*Our* knowing what it means has little to do with whether the software
can figure out what it means. Those are two separate issues.
> (I know there may be ambiguities, but these are not forced on the
> customer by the implementers
They exist within the protocol suite, which we all know to be 'messy'.
We are already doing a whole lot of work on the wire just trying to
figure out what kind of name we have and what kind of service we are
trying to reach. If I were really, truly Anal Retentive I would say we
need four URL prefixes, one for each form of SMB access and one for
each browse list type.
> - rather they are a result of how the customer configures their
I don't see that at all.
> Second, if you are not prepared to spec 'cifs:' url form, then that is
> fine with us. We rely on a 'cifs:' form anyway so we would have no
> problem conforming to your spec if it only covers 'smb:'. In fact,
> DAVE 2.5.2 does not use the smb: url, and the newer (yet to be
> released) version will handle smb: per your draft spec.
The original goal was to have smb: support both browsing and filesharing
via the older NBT transport, and use cifs: for the newer transport. If
you overload smb: so that it handles both, and if that final spec does
*not* support this, your implementatio will be non-compliant.
The whole point of this process is to produce a specification that is a
"best fit" for everyone. I really have done my best to listen to and
encourage discussion. Threats to go your own way defeat the purpose and
> It would appear that a better basis for the cifs: spec would be to
> document the behavior of Windows 2000 when it encounters a file: url
> followed by two slashes, then expand that behavior to include
> additional features such as user credentials.
If it is technically possible *and* technically reasonable to include
support for both browse mechanisms (as it seems to be for file service
transports) then we, as a community, should be considering that as a
viable option. If not, then it makes sense to separate the two
transports, as the current draft suggests. As you point out, the
file:// (as implemented by Microsoft) is not as full-featured as even
the current draft SMB URL.
Christopher R. Hertel -)----- University of Minnesota
crh at nts.umn.edu Networking and Telecommunications Services
-------------- next part --------------
HTML attachment scrubbed and removed
More information about the jcifs