So what's this drive D: stuff we see? It's an experiment, one which seems to be the right thing. Let me tell you about it. We need to provide workspace for clients (that's you, the paying customers) while you work, for your files as well as the Windows swapfile and temp files from applications. The requirement is: such space must be absolutely clean every time you login, and made so very quicky. We can't provide that assurance with local hard disks because they would have to be repartitioned (and maybe low level formatted) and DOS formatted every login, given what some people and nasty software do to systems. In the past we have provided a RAMdrive C: of plump size about 9MB or so which vanishes with the AC power. Today's programs require more space all the time, and your files have become larger yet as graphics are included in documents. These things exceed the capacity of our RAMdrives unless we spend lotsa bucks to upgrade each client from the present 32MB to 64MB (have to lose most of the current SIMMs when doing so because the sockets are full already). The experiment is to use the Novell NetWare file server as surrogate for a local hard disk, and make the writable portion appear as D:. Each station is assigned a work area directory on the server, and it is attached to drive letter D:. That directory is cleaned absolutely during login, and the cleaning process takes only a second or so. There is a different directory for each station, but each looks like D: to its user. At present space is bounded for the collection as a whole, but if someone gets out of line and consumes everything then I will be forced to place space limitations on each station individually. Hint: no games there, please. The cost works out like this. A 4GB SCSI drive (Seagate Barracuda, 7200 RPM, fast, hot) was purchased for the work areas, plus space needed to hold more applications software. To support the new drive server memory was increased. Together this totals about US$2K. Contrast this with upgrading memory in 50 Pentiums, or with putting a non-junk disk drive in each station. The other cost is we will have more network usage, and hopefully this will not saturate us. The Windows swap file can be a bandwidth hog if we aren't careful, but by reducing the RAMdisk to only 3MB we give more memory to Windows and reduce the need to swap. Thus the server-resident swap file ought to be used less than before but it's available when needed. The benefits are much more workspace for you, up to 2GB for the entire lab, and the ability to run larger programs and work on larger projects. The work area will be absolutely clean every login; there is no way a virus can carry over from one login to the next. Automatic backup of MS Word documents is turned on too, at 10 minute intervals, because now we have the space. Note: the work area is cleaned upon every login. Thus if your machine crashes (or the server does, or the AC power goes away) then files in the work area which were closed are still safe. To recover them do NOT login again, yet. Tell the consultant on duty that you need files back, he or she will copy them from your station's work area to a temporary spot, and then after you login the files will be copied to your work area. It's a fallback strategy which we hope will be used only sparingly. We have changed the Novell server operating system from NetWare version 3.12 to NetWare 4.11/beta (code named Green River). A consequence is some utilities, such as login.exe, are much larger and take a little more time to load across the net into a client machine. NW 4 gives us the ability to add more disk capacity without adding a great deal more server memory and to access the space more quickly than with NW 3. Yes, it's a calculated risk, but I believe it is a safe one. Yes, we use Novell's NetWare Directory Services (NDS). "Yes, it runs with Netware" (humor). Comments on how this experiment is working for you would be appreciated. If you have read this far then a few of you are likely to ask "Well, why retain RAMdrive C:?" I knew it. The reason is three files are dynamic: command.com and the two Win95 registry files. Command.com has a transitory portion in memory which is allowed to be clobbered when running programs and consequently must be replaced by reading the file command.com. The Win95 registry files not only change as one resizes windows but also must be in the same directory as command.com. Placing those on drive D: creates significant network traffic every time we turn around. Joe Doupnik jrd@cc.usu.edu -------------------- Now for the technical details, not included in the public notice above. First, the container login script. Notice the cleaning message and the following include file, attached below. Near the end deltree is run to remove debris. map display off map *1:=edu-usu-engrlab_sys: write " Cleaning work area..."; include sys:public\scratch.ncf rem do a castoff in NW 4.11 format - #f:\public\send /a=n >nul map s1:=d:\ map s2:=f:\batch map s5:=f:\masm\bin map s6:=f:\masm\binr map s7:=f:\tools\fortran5\bin map s8:=f:\qpw5 map s9:=f:\qpw5\odapi map s10:=f:\msvc15\bin map s11:=f:\public dos set INIT="d:\\;f:\\masm\\init" dos set HELPFILES="f:\\msvc15\\help\\*.hlp;f:\\masm\\help" dos set MASM="/t" dos set home="d:\\" dos set TMP="d:\\" dos set TEMP="d:\\" dos set PSPICELIB="f:\\wpspice" if OS_VERSION >= "V7.00" then map ins s2:=f:\win95 map ins s3:=f:\win95\command map ins s4:=f:\win95\user #c:command.com /c copy f:\win95\command\attrib.exe c: >nul #c:attrib.exe +r c:\command.com >nul #c:attrib.exe +r c:\net.cfg >nul #c:command.com /c copy f:\win95\user\system.dat c:\ >nul #c:command.com /c copy f:\win95\user\user.dat c:\ >nul #c:attrib.exe +r +s +h c:\system.dat >nul #c:attrib.exe +r +s +h c:\user.dat >nul #c:command.com /c del c:attrib.exe >nul #f:\win95\command\deltree.exe /y d: >nul else #c:command.com /c copy f:\dos\attrib.exe c: >nul #c:attrib.exe +r c:\command.com >nul #c:attrib.exe +r +h c:\net.cfg >nul #c:command.com /c del c:attrib.exe >nul #f:\dos\deltree.exe /y d: >nul map s4:=f:\dos endif write " " write " Good %GREETING_TIME! It's %HOUR24:%MINUTE %DAY_OF_WEEK"; write ", %DAY %MONTH_NAME in Sunny Logan." write " Welcome to the Engineering Student Computer Lab." etc rem #c:\command.com /c copy f:\public\capture.exe c: >nul #c:\command.com /c copy f:\public\nls\english\capture.msg c: >nul #c:capture /l=1 /ff /ti=30 /nb /q=dot-matrix >nul #c:capture /l=2 /noff /ti=40 /nb /q=color /hold >nul #c:capture /l=3 /noff /ti=40 /nb /q=laser /hold >nul #c:capture /l=4 /noff /ti=40 /nb /q=wide >nul #c:command.com /c del c:\capture.* >nul etc drive d: if "%LOGIN_NAME" = "GUEST" then exit endif ------------ File sys:public\scratch.ncf (include'd by container login script). Notice that all Ethernet boards are from the same vendor and hence the leading three octets of the address (six hexadecimal chars) are omitted to save space and time. That is the << 6 trimming. Tiny file y.txt holds "y" to placate MAP when mapping a drive letter below the first network drive (F: here). #c:\command.com /c copy f:\public\y.txt c: >nul machine name="station%STATION" set MACID=P_STATION << 6 if ="13C523" then map r d:=user:r1c1 ="13C427" then map r d:=user:r1c2 ="3475F2" then map r d:=user:3r4c2 ="05AD24" then map r d:=user:printer nul REM supress the error message for empty directory #c:\command.com /c mkdir d:\suppress.err REM Flag all directories and files in D: as Normal #c:\command.com /c copy f:\public\flag.exe c: >nul #c:\command.com /c copy f:\public\nls\english\flag.msg c: >nul #c:\flag d:* n /c /s /DO >nul #c:\flag d:* n /c /s /FO >nul #c:\command.com /c del c:\flag.* >nul #c:\command.com /c del c:\y.txt >nul REM and finally do deltree /y d: at the end of the login script --------- File sys:public\y.txt - y