lishka@uwslh.slh.wisc.edu (a.k.a. Chri) (03/13/91)
A colleague and I are sysadmins of a Novell Advanced Netware 2.15c
network running on an IBM PS/2 Model 80. We have been noticing
horrible problems (which are likely bugs) with MAPs and the use of
volume names with CD.
Our server has several volumes (because we have about 900meg of hard
disk space). Therefore it is necessary for the sysadmins and users to
move around to different volumes to do work. One way of allowing this
is to MAP a drive letter to each volume, and then switch among the
volumes by saying "Z:" or "X:" at a command prompt. This is the
method we are currently using, and we don't seem to have any problems
this way.
Another method we tried in the past was to switch to directories on
different volumes by saying "CD VOLA:\FOO\BAR". Sometimes this
worked; most of the time it did not. The errors we would get would be
varied, but most involved either not switching to the specified volume
or changing to a like directory on the current volume. Sometimes our
MAPs would be completely messed up; other times nothing happened. One
time an instance of a search map was replaced by a map to a local
drive (bizarre!). To our knowledge, none of the errors we have gotten
are reproducible (and believe me, we have tried our best to reproduce
them!).
I have two questions:
(a) Is switching between volumes with "CD VOL:" legal in NetWare?
On one hand, I can see why it would not be legal, given that
drive letters are used almost everywhere (just like in MS-DOS).
On the other hand, NetWare could feasibly provide extensions to
the CD command to allow this sort of thing.
(b) If switching between volumes with "CD VOL:" is not legal, then
WHY THE *&^!@#@$ DOES NETWARE ALLOW THIS TO BE DONE? Is this a
bug in the CD command, or what? Other commands (like MAP and
CHKVOL) allow volume names to be used, although admittedly they
explictly act on volumes. If CD is not meant to act on volume
names, then why doesn't CD report an error if a volume name is
used?
Another problem we have had with volumes and mapping is that if we are
connected to another server by accident and we use this other server's
LOGIN.EXE to login into our server (i.e. LOGIN MYSERVER/MYLOGIN), the
other LOGIN.EXE seems to "eat" the first directory off of the PC's
path. This continues to happen until all of the directories in the
path disappear after repeated LOGINs. It is very annoying! The other
server is also running 2.15c, although the LOGIN.EXE on that server is
older than the LOGIN.EXE on our server. Is this a known bug?
Thanks in advance for any help!
.oO Chris Oo.
Christopher Lishka 608-262-4485 It is not safe out here. It is wonderous,
Wisconsin State Lab. of Hygiene with treasures to satiate desires both
lishka@uwslh.slh.wisc.edu subtle and gross. But it is not for the
uunet!uwvax!uwslh!lishka timid. -- Q
--
Christopher Lishka 608-262-4485 It is not safe out here. It is wonderous,
Wisconsin State Lab. of Hygiene with treasures to satiate desires both
lishka@uwslh.slh.wisc.edu subtle and gross. But it is not for the
uunet!uwvax!uwslh!lishka timid. -- Qboerner@ut-emx.uucp (Brendan B. Boerner) (03/14/91)
In article <1991Mar12.230827.6139@uwslh.slh.wisc.edu> lishka@uwslh.slh.wisc.edu (a.k.a. Chri) writes: [...] >Another problem we have had with volumes and mapping is that if we are >connected to another server by accident and we use this other server's >LOGIN.EXE to login into our server (i.e. LOGIN MYSERVER/MYLOGIN), the >other LOGIN.EXE seems to "eat" the first directory off of the PC's >path. This continues to happen until all of the directories in the >path disappear after repeated LOGINs. It is very annoying! The other >server is also running 2.15c, although the LOGIN.EXE on that server is >older than the LOGIN.EXE on our server. Is this a known bug? If you use MAP S1:=whatever instead of MAP INS S1:=whatever, MAP will eat the path as you describe. Other than that, I'm not familiar with bugs in LOGIN.EXE which will do as you describe. For starters, I'd make sure that all of your servers have the latest LOGIN.EXE. A particularily nasty problem to debug will crop up if you have a LOGIN.EXE which does not support MAP ROOT and you use MAP ROOT in your login scripts and inadvertently use the old LOGIN.EXE. Brendan
saddison@ca.excelan.com (Skip Addison) (03/14/91)
The News Manager) Nntp-Posting-Host: ca Reply-To: saddison@ca.excelan.com (Skip Addison) Organization: Novell, Sunnyvale, CA References: <1991Mar12.230827.6139@uwslh.slh.wisc.edu> Date: Wed, 13 Mar 1991 17:50:06 GMT In article <1991Mar12.230827.6139@uwslh.slh.wisc.edu> lishka@uwslh.slh.wisc.edu (a.k.a. Chri) writes: > ... > I have two questions: > > (a) Is switching between volumes with "CD VOL:" legal in NetWare? No. > On one hand, I can see why it would not be legal, given that > drive letters are used almost everywhere (just like in MS-DOS). > On the other hand, NetWare could feasibly provide extensions to > the CD command to allow this sort of thing. The CD command is an *internal* command of COMMAND.COM. We don't re-write or patch COMMAND.COM. It's part of the DOS command shell. > > (b) If switching between volumes with "CD VOL:" is not legal, then > WHY THE *&^!@#@$ DOES NETWARE ALLOW THIS TO BE DONE? Is this a > bug in the CD command, or what? Other commands (like MAP and > CHKVOL) allow volume names to be used, although admittedly they > explictly act on volumes. If CD is not meant to act on volume > names, then why doesn't CD report an error if a volume name is > used? Other commands (eg. MAP & CHKVOL) are "external" commands. Novell provides the ".EXE" files to make them happen. -- Skip Addison SAddison@Novell.com
lishka@uwslh.slh.wisc.edu (a.k.a. Chri) (03/16/91)
boerner@ut-emx.uucp (Brendan B. Boerner) writes: >If you use MAP S1:=whatever instead of MAP INS S1:=whatever, MAP >will eat the path as you describe. Other than that, I'm not familiar >with bugs in LOGIN.EXE which will do as you describe. No, this is not a problem with "MAP S1: = ..." as opposed to "MAP INS S1: = ...". This only happens when I use the LOGIN.EXE from certain servers. Plus, only one path from my local path (i.e. the path *before* logging in) is eaten each time. >For starters, >I'd make sure that all of your servers have the latest LOGIN.EXE. >[...] This isn't very likely. The "other" servers I am talking about are spread across the Univ. of Wisconsin campus. It would be very hard to get them to update. Actually, it would be very nice if we could "sever" our server from the rest of the campus, but the ethernet which our server is connected to is being used by both the Novell server and our VAX and VAXstation (TCP/IP). Plus, another site connected to our server is also using the ethernet to the "outside world". Oh well. -- Christopher Lishka 608-262-4485 It is not safe out here. It is wonderous, Wisconsin State Lab. of Hygiene with treasures to satiate desires both lishka@uwslh.slh.wisc.edu subtle and gross. But it is not for the uunet!uwvax!uwslh!lishka timid. -- Q