This chapter discusses NetWare volume and directory concepts, examines the default NetWare file system structure, and shows you how to manage the NetWare file system using tools that come with the NetWare 4.x operating system. You also learn about the NetWare file system organization and how to access NetWare directories using the different options of the MAP command.
One of the major features of a NetWare server is a NetWare file system that can be accessed by NetWare clients. Because this NetWare file system is shared by many users, the following points are important:
The NetWare system and utilities are organized into standard directories. Users can be assigned a home directory in which they can keep personal files. If a directory contains system programs meant for network administration, these programs can be restricted for use by network administrators only. Files on the server can be accessed by the workstation's operating system commands. This makes access to the network files simple and intuitive.
NOTE: Home directories are described in more detail in the section "Understanding Directory Structure Organization" later in this chapter.
Because most LANs operate at speeds in the order of megabits per second, access to the server's file system is very fast. Reading and writing a network file to the server is comparable to the speed of reading and writing to a local disk.
STUDY NOTE: Other benefits of NetWare file storage include the following:
- Users can share data.
- Access to file resources is improved.
- Security of data is improved.
- Privacy of data can be protected.
- Management and backup of data is centralized.
The NetWare file system is an extension of the workstation's file system (see fig. 3.1). A Macintosh station views the NetWare file system with the FINDER interface, and a DOS workstation views the file system as a number of remote drives designated by letters such as F:, G:, H:, and so on. The default name space support is DOS. Name space refers to the capability of the NetWare server to provide alternate views of the NetWare file system. The NetWare file system's chameleon-like capabilities are important because a workstation operating system can view the NetWare file system using its own file system conventions.
Figure 3.1 Multiple name space support for NetWare clients.
NetWare offers name-space support for the Unix, Macintosh, and OS/2 operating systems, meaning the clients of those operating systems can access the NetWare file system. Unix workstation support comes with NetWare for NFS products. Macintosh workstation support comes with NetWare for Macintosh products. OS/2 client support is bundled with the NetWare 4.x distribution as NetWare OS/2 Client Requester software.
STUDY NOTE: The default name-space support for the NetWare file system is DOS.NetWare 4.x includes client support for DOS, OS/2, Macintosh, and Unix workstations.
STUDY NOTE: The OS/2 name space provides support for long file names under Windows NT and Windows 95.
The NetWare 4.x operating system presents a logical view of the server's disk. The server's disk is organized into three key areas:
Internally, NetWare manages the disk as a sequence of disk blocks of fixed size. This block size is selectable for NetWare 4.x upon installation (for each volume that is installed) with values of 4 KB, 8 KB, 16 KB, 32 KB, and 64 KB. Treating the disk as a sequence of blocks lets the NetWare file system be independent of the physical disk structure, such as the sectors, cylinders, and disk platters (surface area).
Unused drive letters (usually F: through Z:) are assigned to directories on the server for DOS and OS/2 workstations. After NetWare makes this logical association, the server directories can be treated as extensions to the local disk subsystem. The server's remote file system can be accessed with workstation operating system commands by using a network drive letter.
A server's disk is organized into volumes (see fig. 3.2). Volumes are logical divisions of the space on a server's disk. A volume is the highest-level division of NetWare's file system and roughly corresponds to the partitions of a DOS disk. Although DOS disk partitions are designated by single-drive letters such as C: and D:, the NetWare physical volume names consist of 2 to 15 characters, such as SYS and VOL1. You can only have one NetWare partition per physical drive.
Figure 3.2 NetWare volumes on a server.
A NetWare volume can consist of the entire physical disk, a portion of the disk, or several disks.
A NetWare 4.x server can support 64 volumes. A volume's maximum size is 32 TB (terabytes), which is greater than the capacity of current disks on the market. NetWare 4.x enables a logical volume to span several server disks. This is called volume spanning. A volume can consist of as many as 32 volume segments. Each volume segment is a NetWare partition.
The details of a volume's name, size, and segments are recorded in a Volume Definition Table.
A volume's capability of spanning several disks is advantageous for applications with extremely large files that won't fit onto a single disk. This feature also enables several I/O operations to be done simultaneously, because the volume can have a number of separate disks and disk controllers that provide simultaneous access to it. Requests to access a volume don't have to be queued up. As long as the requests refer to an area of the volume that's on a separate disk, those requests can be processed by the separate disk controllers and drives.
Volume spanning does have its negative features, however. If any of the disks comprising a volume fails, the entire volume fails. When volumes span multiple hard drives, Novell recommends that SFT Level II disk mirroring or duplexing be used to prevent data loss as a result of drive failure; however, this can be a very expensive solution when large disks are involved.
The first volume in a NetWare server is always named SYS:. This volume holds the NetWare NOS and its program and data files. Other volumes can have names of 2 to 15 characters.
NOTE: The physical name of the first volume that the NetWare server will mount is SYS.Keep volume names simple. The first volume after SYS: for example, can be labeled VOL1:, the next one VOL2:, and so on. You can alternatively give more descriptive names for volumes.
NetWare volumes are referred to by a volume name, which can be of two types:
The syntax of these volume names is discussed in the following sections.
Physical volume names should maintain compatibility with the NetWare 3.x naming convention. Volumes attached to server FS1 with the physical names of SYS and VOL1, for example, can be referred to by the following NetWare 3.x syntax:
FS1/SYS: to reference the SYS volume
FS1/VOL1: to reference the VOL1 volume
The physical volume name must follow several naming rules, including:
A to Z
0 to 9
$ ~ - _ # ! % ^ & ) ( } {
space ( ), backslash (\), period (.), comma (,)
FS1/SYS: FS1\VOL1:
FileServerName\PhysicalVolumeName
FS1\VOLA: FS2\VOLA:
Remember the volume name rules listed in this section for your exams.
The physical volume name is created during server installation (see fig. 3.3).
Figure 3.3 NetWare volumes created at installation.
A Volume object name is created with the physical volume name during server installation (see fig 3.4). Every physical volume name has an NDS object name counterpart. The Volume object name for a physical volume is its NDS object name. The Volume object is placed in the same context as the File Server object, and its name is derived from the file server using the following rule: The default Volume object name is a concatenation of the File Server object name, the underscore character (_), and the physical object name.
Figure 3.4 Volume object naming.
A volume with the physical name PhysicalVolumeName and attached to the server called ServerName has the following Volume object name:
ServerName_PhysicalVolumeName
Table 3.1 provides examples of the application of this rule.
Table 3.1 Examples of Building Volume Object Names
Server Name | Physical Volume Name | Volume Object Name |
FS1 | SYS: | FS1_SYS |
LTREE1 | VOL1: | LTREE1_VOL1 |
FS_CORP | CORP_VOL: | FS_CORP_CORP_VOL |
KSS_FS | APP$ENG!VOL | KSS_FS_APP$ENG!VOL |
The Volume objects contain properties such as the host server name and the physical volume name that refer to the Server object and its physical name. Though the Volume object names are created in the context in which the File Server object is placed, they can be moved to a different context. You should keep the Volume objects in their default context (same as server context) because they're most likely to be used by User objects defined in this context. Keeping Volume objects in their default context also helps avoid confusion with the location of Volume objects.
Because Volume object names refer to the Volume object in the NDS tree, you can use the NDS syntax to refer to its name. To refer to the Volume object name FS1_SYS in the context OU=CORP.O=SCS, you can use any of the following:
.CN=FS1_SYS.OU=CORP.O=SCS .FS1_SYS.CORP.SCS FS1_SYS (if current context is OU=CORP.O=SCS)
A volume can be divided into directories and files, and directories can be further divided into subdirectories. Directories and subdirectories help users organize files.
NetWare supports a hierarchical file structure. Figure 3.5 illustrates the hierarchy of dividing a volume into directories and files. For DOS workstations, the file and directories follow the 8.3 naming rule--that is, eight-character file names with three- character extensions. Because DOS is the default name space for the NetWare file system, DOS rules for naming directories should be used for DOS workstations. The following is a summary of the DOS name space restriction rules:
A to Z
0 to 9
$ ~ - _ # ! % ^ & ) ( } {
Figure 3.5 NetWare directory structure versus DOS directory structure.
STUDY NOTE: Remember the DOS name rules for NetWare files listed in this section.
You can refer to a file on this server using the NetWare 3.x file naming syntax. In this case, bindery emulation is used to resolve the file name. In the NetWare 3.X syntax, the full path name of the file consists of the following:
[serverName/]volName:dir1{/dir2}/fileName
The directory separator delimiter character can be a forward slash (/) or backslash (\). Examples of NetWare path names are as follows:
In the first example, the path name includes the name of the server KSS. The volume name is SYS. The first directory is PUBLIC, and the subdirectory is SCRIPTS. The file name is STUDENTS.SCR.
In the second example, the optional server name is not listed. This implies that the server name of the default server will be used. Under the volume name SYS: is the directory APPS that contains the file README.DOC.
In the third example, the optional server name again is not listed. The volume name is VOL1:; the directory name is BRIGHT. BRIGHT has a subdirectory named DOC that contains the file MANUAL.DOC. Both the forward slash (/) and backslash (\) are used as directory separators. Although either one is all right, you should use one consistently.
Because a NetWare volume is a leaf object in the NDS tree, the directories and file path names can use the NDS syntax to refer to the volume name. Figure 3.6 shows the path name for subdirectories ENG and CORP that are in the COMMON subdirectory in the Volume object FSDEV_SYS. The Volume object is in the context OU=CORP.O=LGROUP. If the current context is O=LGROUP, the following partial NDS names can be used to refer to the Volume object:
FSDEV_SYS.CORP.LGROUP CN=FSDEV_SYS.OU=CORP.O=LGROUP
Figure 3.6 NDS syntax for file names.
To refer to the subdirectory CORP or ENG, the Volume object name must contain the file directory path as a prefix (COMMON/CORP or COMMON/ENG). The Volume object name and the directory path are separated by the colon (:) delimiter. Therefore, the CORP and ENG directories can be referred to by the following syntax, if the current context is O=LGROUP:
FSDEV_SYS.CORP.LGROUP:COMMON/CORP CN=FSDEV_SYS.OU=CORP.O=LGROUP:COMMON/ENG
If the current context is OU=CORP.O=LGROUP, the following partial NDS names can be used to refer to the Volume object:
FSDEV_SYS CN=FSDEV_SYS
To refer to the subdirectory CORP or ENG, the Volume object name must contain the file directory path as a prefix (COMMON/CORP or COMMON/ENG). Therefore, the CORP and ENG directories can be referred to by the following syntax, if the current context is OU=CORP.O=LGROUP:
FSDEV_SYS:COMMON\CORP CN=FSDEV_SYS:COMMON/ENG
Again, you can use the backslash (\) or forward slash (/) to separate file directory names.
Instead of using partial names for the Volume object (as in the previous examples), you also can use complete names, as shown in the following example (notice that complete names must have a leading period):
.FSDEV_SYS.CORP.LGROUP:COMMON/CORP .CN=FSDEV_SYS.OU=CORP.O=LGROUP:COMMON/ENG
The first example uses typeless complete names for the Volume object, and the second example uses complete names with attribute type designators (CN, OU, O).
The normal method of naming files is to start from the top of the directory tree and enumerate the directories separated by the delimiter backslash (\) or forward slash (/), all the way down to the file or directory. The NDS naming convention, however, is the opposite of this. Here, you start with the bottom of the tree and list the object names separated by the delimiter period (.) all the way up to the [Root] object. The [Root] object isn't listed because a NDS tree can have only one root.
When you name file directories using the NDS syntax, you're combining the NDS and file-naming conventions. Figure 3.7 shows that these two conventions can be thought of as going up a hill to list the NDS path name. The colon character, listed at the peak of the hill, marks the switch to the file-naming convention. The file-naming convention lists the file directories beginning with the root directory and goes down the hill to the file or directory.
In summary, when combining NDS syntax for volume names with NetWare file system directory syntax, remember the following:
Figure 3.7 Combining NDS syntax and file-naming syntax.
During server installation, a default directory structure is created in the first installed volume. This directory structure is listed in figure 3.8. Table 3.2 shows the purpose of each of the major default directories.
The NLS subdirectories under the LOGIN, PUBLIC, and SYSTEM directories contain the unicode files for international language support. The NLS directory contains further subdirectories that identify the installed language support. If the default language ENGLISH is installed, subdirectories will be named LOGIN\NLS\ENGLISH, PUBLIC\NLS\ENGLISH, and SYSTEM\NLS\ENGLISH.
Figure 3.8 Default directory structure on first volume of each server.
The DOC directory is created if you've installed the online DynaText files and documentation. The QUEUES directory is created if the volume is used for implementing storage for print queues.
Table 3.2 Default Directories
Installed Directory | Description |
SYS:LOGIN | Contains LOGIN.EXE, CX.EXE, and other programs for logging in to the network. |
SYS:PUBLIC | Contains NetWare commands and utilities available to users. |
SYS:SYSTEM | Contains files used by the system administra-tor and the NetWare operating system. NLMs (NetWare Loadable Modules) also are kept here. |
SYS:MAIL | Mail directory. Usually empty in NetWare 4.x but may have subdirectories if upgrading from NetWare 3.x. |
SYS:DOCVIEW | Contains DynaText Viewer program files and documentation. |
SYS:DOC | Contains the actual data files for DynaText. |
SYS:QUEUES | Contains directories for NetWare print queues. |
SYS:ETC | Contains files for configuring TCP/IP. SYS:ETC/SAMPLES contains sample files that can be customized. |
SYS:DELETED.SAV | Contains file from directories that can be salvaged (deleted but not purged). |
NLS subdirectories | The NLS subdirectories are created in SYS:LOGIN, SYS:PUBLIC, and SYS:SYSTEM. They contain the message and Help files for national languages support for the utilities found in these directories. |
STUDY NOTE: Remember the default installed directories and their purpose as listed in table 3.2.
The LOGIN directory contains the NetWare utilities LOGIN.EXE, NLIST.EXE, CX.EXE, and several others. The LOGIN directory also holds the operating system boot images created by the DOSGEN program for diskless workstations. Some LAN managers keep other copies of programs that they want to be widely available to users without restrictions, such as a program for detecting viruses.
The default access rights to the SYS:LOGIN directory prevent modification of programs in this directory. Care must be exercised to see that these default access rights are not changed. Otherwise, the LOGIN directory can become a place through which a virus attack can spread.
The PUBLIC directory contains the NetWare utilities used by most users; for this reason it is added to the search path. A copy of LOGIN.EXE, NLIST.EXE, and CX.EXE also are kept here in case they become corrupted in the LOGIN directory. Again, care must be taken to limit access to SYS:PUBLIC for running NetWare utilities and not modifying them accidentally or maliciously.
The SYSTEM directory contains the NetWare operating system files and system programs. Access to SYS:SYSTEM should be limited to system administrators and special management utilities that might need to access SYS:SYSTEM.
The SYSTEM directory contains the NetWare Loadable Modules for the operating system, startup files (.NCF), and server drivers. This is because SYS:SYSTEM is the default search path for NLMs loaded from the server console.
Earlier versions of NetWare distributed an e-mail program called MAIL. The e-mail messages were stored in the user ID subdirectory in SYS:MAIL, along with the user's login script. Distribution of the e-mail program was discontinued, but the name of the directory (MAIL) was kept the same. In earlier NetWare versions, the MAIL directory contained the login scripts for the users defined on the NetWare server. In NetWare 4.x, login scripts are kept in the NDS database as a property of a User, Profile, Organization, or Organizational Unit object. If you're upgrading a NetWare 3.x server to a NetWare 4.x server, the older login files that are kept in the MAIL directories will be kept in the SYS:MAIL directory, even though these login scripts will not be used when logging in as an NDS user. If you are running bindery emulation in the SYS:MAIL directory, these login files will be used. Also, the correct SYS:MAIL directory can be created by entering LOGIN <username> /b.
Novell recommends that a directory structure be used to help organize the network files and directories. Figure 3.9 shows one possible structure, with separate directories for different DOS versions, users' home directories, applications, and configuration information.
Figure 3.9 Recommended directory structure.
STUDY NOTE: Please study the Novell recommendation on the different types of directory structures carefully. You may be presented with a scenario of a number of applications and users on a server and asked about the best selection among several NetWare file system directory configurations. These directory configurations will be presented graphically.
The DOS directories hold different versions of DOS programs and utilities installed on NetWare workstations. This capability is useful for keeping a shared copy of the DOS versions used by workstations.
Because many versions of DOS can be used on the network, Novell recommends the directory structure shown in figure 3.9 for storing DOS programs. To support this directory structure, NetWare defines a number of login script variables. These script variables can be used to specify directories in the login script, and are mapped into values shown in figure 3.9. Thus, the login script variable %MACHINE can map into values IBM_PC or COMPAQ, and the script variable %OS_VERSION can map into version numbers such as V3.20, V3.31, V5.00, and V6.20. Depending on the DOS version and machine type, the appropriate network directory can be specified by using the generic script variables. The value of script variables such as %MACHINE can be explicitly controlled by the LONG MACHINE TYPE parameter in the NET.CFG workstation configuration file. The procedures for creating login scripts are described in Chapter 6.
All workstations should use the same DOS version to minimize maintenance problems, but this is not always possible. If users of the network belong to different departments that have different budgets, the departments might be using different DOS versions. Also, some older network applications might only work with a particular DOS version. The DOS directory should have a copy of COMMAND.COM for each DOS version supported on the network; having these copies in the DOS directory ensures proper exit from applications when the transient copy of the overwritten COMMAND.COM needs to be written back.
NOTE: If the directory structure shown in figure 3.9 is used, you must be careful to avoid license infringements. Each user on a DOS workstation must have a license.
A home directory is a directory on the server disk reserved for a user to keep personal files. The user usually has unrestricted access to the home directory because the home directory is an extension of the local disk space at the user's workstation.
Home directories can be organized under a directory named USERS or HOME. The users' home directories can be created as subdirectories under the parent USERS or HOME directory. Users get full access to their home directories when the home directory is created using utilities such as NETADMIN, NWADMIN, and UIMPORT. Users are free to organize their home directories any way they want. The home directory should be the same as the user's login name to assist in its identification, and to enable the use of common script files that can refer to a user's home directory by using the login script variable %LOGIN_NAME.
PRACTICAL TIP: In secure environments, you might want to remove the Supervisor and Access Control rights for users to their home directories. These rights enable the users to grant access for their home directories to other users on the network.
Application directories are used for network applications on the network. You can install applications in their own subdirectories under a common directory called APPS. These directories are shared by all users, so only application programs and data files that need to be shared should be kept here. Temporary files created during the execution of an application should not be kept here, unless the application can recognize the temporary files created by different users and subsequently remove those files on application exit.
PRACTICAL TIP: Always try to keep the TMP and TEMP variables pointed at a local drive when creating and accessing NetWare files, because this avoids network traffic.
Configuration directories can be created for individual user customization or for all users. This supports applications that maintain separate configuration files for each user. An example of such an application is a WordPerfect program that stores a configuration file for users based on their three-letter initials. If users need to modify the configuration files, you should keep the configuration files in the CONFIG directory under the user's home directory. If configuration files need to be maintained by the application, they should be placed in the application's directory.
The Shared data directory acts as a clearinghouse for distributing information. You can use NetWare file system security to ensure that only designated users have access to this directory. Many network administrators prefer not to have the shared data directory, because it requires periodic maintenance to ensure that old files are removed.
Figure 3.10 shows an example of a one-volume directory structure. This assumes that only one volume is on the server and you are dealing with a very small number of users who need access to the server. In this figure, the users' home directories are created directly under the root of volume SYS, instead of under the USERS or HOME directory. You can, if you want, create the home directories under a common USERS or HOME directory. Figure 3.10 also shows separate CORP and ACCT directories to maintain applications for different departments (Corporate and Accounting) in separate directories.
Figure 3.10 Single-volume directory structure.
Figure 3.11 shows an example of a multiple-volume directory structure. This assumes that the server contains multiple volumes, and that volumes are dedicated for a specific use, such as the following:
Figure 3.11 Multiple-volume directory structure.
In figure 3.11, the SYS: volume holds the standard NetWare file systems in the LOGIN, PUBLIC, and SYSTEM directories. Certain applications common to all departments are stored in the SYS:APPLIC directory. Volume ACCT is dedicated for accounting department users and the applications they use, and volume ENGINEERING is dedicated for engineering applications and engineering users' home directories.
A number of factors should be considered before a file system directory structure is established, including the following:
You can expect to apply these criteria in some of the questions on the CNE exams.
The system administrator can manage the network file storage using the following commands and utilities:
These commands are discussed in the following sections.
A brief overview of the many options of the NLIST command can be obtained by using the NLIST /? command. Many of the options were discussed in Chapter 2, "Introduction to NetWare Directory Services."
The NLIST VOLUME command displays information on volume subjects, such as the following:
Figure 3.12 shows the output of the NLIST VOLUME /S command. In this example, the current context is O=ESL. Several Volume objects were found in the subtree O=ESL. When you use the NLIST VOLUME command without any options, you must be in the proper context to see the Volume objects. To see all Volume objects in subcontainers, you can use the /S option. The /CO option, which uses the context specified for the NLIST command, is very useful. For example, to view all Volume objects in Organization O=SCS, type the following:
NLIST VOLUME /S /CO "O=SCS"
Figure 3.12 The NLIST VOLUME /S command.
Some other useful NLIST VOLUME commands are listed in table 3.3. The examples are not exhaustive, but are listed so that you can understand how the NLIST VOLUME command can be used.
Table 3.3 NLIST VOLUME Command Examples
Task | Command |
List information on volumes | NLIST VOLUME in current context |
List information on volumes | NLIST VOLUME /S and subcontainers in current context |
List only names of volumes | NLIST VOLUME /Nin current context |
List detailed information on | NLIST VOLUME /D volumes in current context |
The NDIR command is the network version of the DOS DIR command. It performs the following functions:
The NDIR command syntax is shown in figures 3.13 through 3.19. These figures can be obtained using the NDIR /? command. Use these figures as a quick review of the NDIR options when preparing for your CNE exams.
Figure 3.13 NDIR General Usage Help.
Figure 3.14 NDIR Format Specification Help.
Figure 3.15 NDIR Attributes Specification Help.
Figure 3.16 NDIR Sort Specifications Help.
Figure 3.17 NDIR Restrictions Specification Help.
Figure 3.18 NDIR Options Help.
Figure 3.19 NDIR Syntax Help. Here's an example of the use of the NDIR command:
F:\>NDIR SYS:PUBLIC Files = Files contained in this path Size = Number of bytes in the file Last Update = Date file was last updated Owner = ID of user who created or copied the file FS1/SYS:PUBLIC\*.* Files Size Last Update Owner ALLOW.BAT 26 9-24-92 11:48a FS1 APLASER2.PDF 2,986 1-17-92 3:23p FS1 APPIMAGE.PDF 327 10-25-89 11:49a FS1 APPLASER.PDF 1,281 8-14-90 3:57p FS1 : : 16,335,472 bytes (24,903,680 bytes in 380 blocks allocated) 167 Files 4 Directories
Figure 3.20 shows the output of the NDIR /VOLUME command. This command shows statistics on the current volume. The statistics are for volume NW4CS/SYS:. It displays the total volume space, deleted space not yet purgeable, space remaining on volume, and space remaining on volume for the user who issued the command. The NDIR /VOLUME command also displays volume compression information if compression is enabled for the volume.
Figure 3.20 NDIR /VOLUME command output.
The NDIR /DO command displays only information on directories. Figure 3.21 shows an example of this command's output. The NDIR /DO command was issued from the root of volume NW4CS/SYS:. It shows that nine directories were found and shows the Inherited Rights Filter (IRF) for each directory, the effective rights for the directory for the user issuing the command, and the directory-creation time stamp. Notice that certain default directories such as SYS:LOGIN, SYS:PUBLIC, SYS:SYSTEM, SYS:DELETED.SAV were created during installation. This is a quick way of determining when a particular installation was done. The owner of the directory also is displayed.
Figure 3.21 The NDIR /DO command.
The NDIR /FO command displays only information on files. Figure 3.22 shows an example of this command's output. It shows that the root of the SYS: volume has three files: BACKOUT.TTS, TTS$LOG.ERR, and VOL$LOG.ERR. These are important files for the network administrator to know. The first two deal with the Transaction Tracking System (TTS) that enables incomplete transactions to be backed out. The VOL$LOG.ERR shows errors that have been recorded for that volume.
Figure 3.22 The NDIR /FO command.
To list directory information only within the current directory and all subdirectories within the current directory, you can use the /SUB option, as follows:
NDIR /DO /SUB
To list only files in the current directory and all subdirectories within the current directory, use the following command:
NDIR /FO /SUB
To list all directories within the current directory and all subdirectories in the SYS: volume that have the letters WAN as part of the directory name, you can use the /SUB option, as follows:
NDIR SYS:*WAN* /DO /SUB
To display a list of files only sorted by the last modified (updated) time stamp, use the following command:
NDIR /FO /SORT UP
To display a list of files sorted by the most recently accessed time stamp, type the following command:
NDIR /FO /SORT AC
To sort a directory list of files by size, with the largest file first (reverse sort), type the following command:
NDIR /FO /REV SORT SI
For details of other sort options, refer to figure 3.16.
To list files that have not been modified before a certain date (Oct 16, 1993), type the following command:
NDIR /FO /UP BEF 10-16-93
To list files that have been modified after a certain date (Nov 20, 1993), type the following command:
NDIR /FO /UP AFT 11-20-93
To list files in SYS:PUBLIC that have long file names (such as those supported by NFS and OS/2 name spaces), type the following:
NDIR SYS:PUBLIC /L
or
NDIR SYS:PUBLIC /LONG
To list all files in SYS:DATA directory that have a Read Only attribute, type the following command:
NDIR SYS:DATA\*.* /RO
To list all files in SYS:DATA directory that do not have a Read Only attribute, type the following command:
NDIR SYS:DATA\*.* /NOT RO
To display all files owned by user KSS, type this command:
NDIR SYS:*.* /SUB /OW EQ KSS
To display all files not owned by Admin, type the following command:
NDIR SYS:*.* /SUB /OW NOT EQ Admin
To display additional information on compressed files, type this command:
NDIR /COMP
The /COMP option displays compressed and uncompressed sizes of each compressed file as well as the percentage of space saved as a result of compression.
Examples of useful NDIR options are summarized in table 3.4.
Table 3.4 NDIR Examples
Option | Meaning |
/SUB or /S |
Display information on subdirectories also. |
/C | Continuous display. Do not pause for user input if more than one screen of display information. |
/SORT | Sort in ascending order. Sort criteria is file name (default). |
/REV SORT |
Sort in descending order. Sort criteria is file name (default). |
/VER | Displays version number stored in NetWare utility program files. |
/COMP | Displays compression information on files. |
/FO | Displays files only. |
/DO | Displays directories only. |
/OW | Owner information. Example: /OW EQ ADMIN. |
/LONG or /L |
Shows long file name space support for non-DOS name spaces such as NFS, OS/2, and Unix. |
STUDY NOTE: Be familiar with the use of the NDIR options listed in table 3.3.
NDIR wild card searches work differently than in DOS. The asterisk (*) is used to match zero or more characters. In DOS, the asterisk matches any file-name pattern. The following commands show the differences between the DOS DIR and NetWare NDIR wild cards. The examples show the wild card pattern *W*.* on the directory list of the F:\USERS\KARANJIT directory for the DOS DIR and NetWare NDIR commands. The DOS version used in the examples is DOS 5. The directory has three files. Notice that the DIR *W*.* matched all files in the directory, whereas the NDIR *W*.* found only the single file that correctly matches this file pattern:
> DIR *W*.* Volume in drive F is SYS Directory of F:\USERS\KARANJIT AWK EXE 36027 07-04-92 3:21p COPYQM COM 28451 12-10-92 5:30p TEST TXT 2 06-10-93 4:34p 3 file(s) 64480 bytes 103972864 bytes free >NDIR *W*.* NDIR is searching the directory. Please wait... Files = Files contained in this path Size = Number of bytes in the file Last Update = Date file was last updated Owner = ID of user who created or copied the file NW4CS/SYS:USERS\KARANJIT\*W*.* Files Size Last Update Owner ________ ______ ___________ _____ AWK.EXE 36,027 7-04-92 3:21 Admin 36,027 bytes (49,152 bytes in 3 blocks allocated) 1 File
Many of the DOS commands that work with the DOS file system also can be used with the NetWare file system. Examples of such commands are the DOS MD (Make Directory) and RD (Remove Directory) commands.
NetWare supports a RENDIR command that's used for renaming directories. It has the following syntax:
RENDIR directory_path [TO] new_directory_path
The following are examples of this command:
RENDIR SYS:APPS/SHARED SYS:APPS/COMMON RENDIR F:\USERS\KIMS TO F:\USERS\KIMJ
The RENDIR command also can be used on local drives to rename directories on local hard disks:
RENDIR C:\UTILS TO BIN
The previous command renames C:\UTILS to C:\BIN.
STUDY NOTE: The RENDIR command can be used to rename NetWare directories and local directories.
The NCOPY command copies files or directories from a server directory to a server directory without using the workstation as an intermediate point (see fig. 3.23). This command preserves NetWare file extended attributes that are different from those available in DOS.
Figure 3.23 also shows the differences between the DOS COPY command and the NCOPY command. The DOS COPY command copies data to the workstation and then back from the workstation to the server. This involves a considerable amount of network traffic. With the NCOPY command, the file's destination and source are at the same server, and no network traffic is involved.
Figure 3.23 DOS COPY command versus NCOPY command.
The general syntax for the NCOPY command is as follows:
NCOPY source_path [TO] destination_path
To copy file SYS:DATA\X.TXT to VOL1:COMMON\DATA, type the following command:
NCOPY SYS:DATA\X.TXT VOL1:COMMON\DATA
When the previous copy command is executed, no traffic is generated because the volumes are on the same server. If the source and destination volumes are attached to different servers, network traffic is generated--as seen in the following example that shows a copy of a file between servers FS1 and FS2:
NCOPY FS1/SYS:DATA\X.TXT FS2/SYS:DATA\X.TXT
To copy all files in the current directory to another location--including subdirectories and empty subdirectories--use the following command:
NCOPY FS1/SYS:CONFIG /S /E
The /C option ensures that only DOS information is copied. NetWare extended-attribute information is copied without the /C option. To copy file MYFILE.DOC to another location and not preserve NetWare extended attribute information, type this command:
NCOPY MYFILE.DOC SYS:APPS/WP /C
If you want to be notified that non-DOS file information (NetWare extended attributes) will be lost when the NCOPY command is used, add the /I option to the command. This option is also valuable if you're copying name-space information to a volume that does not support it. The /I option warns you if the name space information will not be copied.
The /R option for the NCOPY command copies the file in the compressed state. If a compressed file is copied, it's copied to the destination in an uncompressed state. To force the copying of a file in the compressed state, you can use the /R (Retain Compression) option.
If you are copying a file to a different volume, that volume should have compression enabled. Compression is enabled for a volume during volume installation time. You can use the /RU (Retain Uncompressed) option to force the copying of a file in the compressed state--even if the destination volume doesn't support NetWare's compression. An example of this use could be copying a file temporarily to a local DOS drive. Data in the copied file cannot be accessed unless it is copied back to a NetWare volume that has compression enabled. Thus, to copy the file SYS:APPS/DATA/GL.DAT to the C: drive in a compressed state, type the following:
NCOPY SYS:APPS/DATA/GL.DAT C:\ /RU
The /M option copies files that have an archive bit set and then clears the archive bit. This enables the copying of files that have not been backed up.
If you want to copy files that need to be backed up to another location and be notified if extended file information will not be copied, type the following:
NCOPY *.* H:\BCPY /M /I
The NCOPY command has an /F option that works with sparse files. Sparse files have one or more empty blocks. Examples of applications that use sparse files are graphical, imaging, and database applications. The /F option forces the NCOPY command to write the empty disk blocks when copying sparse files. An example of the /F option follows:
NCOPY FSDB/VOLDB:APPS/DATA/*.* FSBK/SYS:BU /F
Figure 3.24 shows the help obtained using the NCOPY /? command. This figure shows the details of other NCOPY options.
STUDY NOTE: Study the NCOPY examples in this section and the NCOPY options listed in figure 3.24.
Figure 3.24 NCOPY General Help (NCOPY /?).
The NetWare Administrator (NWADMIN) can be used for managing files and directories as well as salvaging and purging files. It's a GUI utility that runs under MS Windows. The NWADMIN program is normally associated with management of NDS objects, but can be used for managing files and directories in a volume because the Volume object is an NDS object. Double-clicking on an NDS object reveals the subdirectories stored in that volume. The information is displayed in a graphical tree (see fig. 3.25).
Figure 3.25 Using the NWADMIN program for file and subdirectory management.
Figure 3.25 displays the subdirectories for Volume object NW4CS_SYS in the context OU=CORP.O=ESL. The directories are listed in alphabetical order. The home directories for user DEI and KARANJIT are also displayed under the USERS directory. The file names BACKOUT.TTS, TTS$LOG.ERR, and VOL$LOG.ERR at the root of the Volume object NW4CS_SYS also are displayed. To examine the contents of any directory, you can highlight and select that directory (double-click if you're using a mouse).
STUDY NOTE: The NetWare Administrator (NWADMIN) can be used for file management.
The FILER program is a text-based menu utility that enables you to perform the following tasks:
Figure 3.26 shows the FILER main menu and the options that are available.
Figure 3.26 The FILER main menu.
The Manage files and directories option displays a list of subdirectories and files in the current directory. Selecting a directory displays its contents. Selecting a file enables you to copy, view, or move a file. Additionally, you can view and set file information such as file attributes, owner, Inherited Rights Filter (IRF), file trustees, creation date, last accessed date, last archived date, and last modified date. You also can display a list of rights for a file.
To perform operations on a directory, you must highlight the directory and press F10. For directories, you can copy a subdirectory's files, copy a subdirectory's structure, move a subdirectory's structure, make it your current directory, view trustees of the directory, or view/set directory information.
The Manage according to search pattern option enables you to select files and directories that only match a certain pattern. The default search pattern is *.* for all directories and files. You can select to exclude or include patterns for files and directories. You also can search based on file or directory attributes.
The Select current directory option enables you to select the current directory path.
The View volume information option enables you to observe volume statistics, volume features, and volume creation and modification date and time stamps. Volume statistics include total volume space in KB, active space used, deleted space not yet purgeable, space remaining on volume, maximum directory entries, and directory entries available. The volume features include volume type (removable, non-removable, and so on), volume block size, name spaces installed on the volume, and installation features (compression, migration, suballocation, and auditing). The dates and times for the volume include creation date and time, volume owner, last modified date and time, and last archived date and time. The last user to archive the volume also is shown.
The Salvage deleted files option enables you to view/recover deleted files, salvage from deleted directories, and set salvage options.
The Purge deleted files option enables you to select the file name patterns to purge by. In NetWare, files that have been deleted can be set to be recoverable, unless they're purged. When files are purged, they cannot be recovered. The default is * (all files).
The Set default filer options option enables you to control filer settings that affect its behavior. You can, for example, configure a filer to confirm deletions, confirm file copies, confirm file overwrites, preserve file attributes, notify you if name-space information is lost, copy sparse files, copy compressed files, and force files to be copied in compressed form.
Certain applications can store files in sparse format. This means that because most of the file blocks contain repeated patterns (all zeros, for example), the file can be maintained by the application in a special sparse format. If the copy files sparse format is set, NetWare does not expand the file to its non-sparse format while making a file copy.
STUDY NOTE: Make sure you know the capabilities of FILER listed in this section.
This section shows you how to use the commands and utilities discussed in the previous sections. Follow these steps:
CX /R
NLIST VOLUME
NLIST VOLUME /S
PRACTICAL TIP: The number of Volume objects reported by the NLIST command might be more than the actual number of physical Volume objects. This would be the case if some of the Volume objects are alias objects that point to other Volume objects. The NLIST command does not distinguish between alias object names and the real object names.
NLIST VOLUME
7. To see only the object name, use the /N option, as follows:
NLIST VOLUME /N
NLIST VOLUME /D
NLIST VOLUME /CO .OU=ENG.O=SCS
The previous command lists information on Volume objects in another context without changing your current context. You might want to use the command CX to verify that your context has not changed.
The following steps show you how to explore the volume with the NDIR command.
NDIR SYS:SYSTEM /S /DO
NDIR SYS:SYSTEM /S /FO
NDIR SYS:SYSTEM /FO /SORT SI
NDIR SYS:SYSTEM /FO /REV SORT SI
NDIR SYS:*.EXE /FO /SUB /UP AFT 6-1-93
NDIR SYS:PUBLIC\*.EXE /FO /SUB /AC BEF 1-1-93
To make use of the NetWare file system, the workstation assigns one of the available network drives to a directory on the server. This process is called mapping a network drive. Figure 3.27 shows the available drive letters. Drive letters from A: to E: are usually reserved for local drives, and drives F: to Z: can be used for network drives. The figure also shows search drive mappings, which will be discussed later in the chapter.
Figure 3.27 Local, network, and search drives.
NetWare 4.x requires that you have the LASTDRIVE=Z statement in the CONFIG.SYS file of the NetWare DOS workstation, because the drive table data structure is shared by both DOS and the NetWare requester. The FIRST NETWORK DRIVE statement can be used in the NetWare DOS Requester section of the NET.CFG file to assign which drive letter will be used as the first network drive. If the FIRST NETWORK DRIVE statement isn't used, the first drive letter that isn't used for a local drive or device becomes the first network drive.
The NetWare shell that was used with older versions of NetWare used the LASTDRIVE statement in the NET.CFG to define the last local drive available to the workstation. The next drive letter after the LASTDRIVE letter became the first network drive. Because the default value of LASTDRIVE was E:1 E:, the first network drive became F:. To preserve compatibility with the older convention of starting the first network drive as F:, many NetWare 4.x installations set FIRST NETWORK DRIVE=F in the NetWare DOS Requester section of the NET.CFG file.
STUDY NOTE: In NetWare 4.x DOS workstations, the LASTDRIVE=Z statement must be in the CONFIG.SYS file.
The MAP command assigns a drive letter to a NetWare server directory. The general syntax of the MAP command is shown in figures 3.28 and 3.29. In figure 3.28, you can see that the MAP command has a number of parameter options that precede the drive letter. These options will be discussed next. The = path syntax specifies a directory path and is used when performing a drive mapping. When the DEL (or REM) option is used with the MAP command, the directory path is not specified.
Figure 3.28 The MAP command.
Figure 3.29 MAP General Help (MAP /?).
STUDY NOTE: You should be familiar with the MAP command options listed in figures 3.28 and 3.29.
Here are a few examples of use of the MAP commands:
MAP F: = SYS:PUBLIC MAP G: = SYS:USERS MAP H: = SYS:
The drive letters and their associated network directories are shown in figure 3.30.
Figure 3.30 Examples of the MAP command.
In DOS, you can use the PATH command to specify the order in which directories are searched (if a program file isn't found in the current directory). The directories specified in the PATH command are stored in a DOS environment variable of the same name (PATH).
You can't include NetWare directories as part of the PATH command using the NetWare syntax for a directory. Consider a situation in which a DOS station has the following setting for the PATH environment variable before logging on to a NetWare server:
PATH=C:\WP51;C:\BIN;C:\BC\BIN;C:\WC386\BIN
To add a NetWare directory SYS:PUBLIC\UTIL to the beginning of the search path, you might be tempted to use the following DOS PATH command:
PATH=SYS:PUBLIC\UTIL;C:\WP51;C:\BIN;C:\BC\BIN;C:\WC386\BIN
This command, however, won't work because most commands are executed at the workstation. For a DOS workstation, this means that the command will be executed under DOS. When DOS tries to process the SYS:PUBLIC\UTIL directory in the PATH environment variable, it gets confused by the SYS:. It expects to see a one-letter drive; instead, it finds a three-letter name, SYS. NetWare provides an easy way out of specifying network directories as part of the search path by making use of search drives.
Search drives are shown in figure 3.27. Sixteen are available, and they are labeled SEARCH1 through SEARCH16. The common abbreviation is to replace the word SEARCH with the letter S. Thus, the first search drive can be abbreviated as S1 and the sixteenth search drive is abbreviated as S16.
Search-drive assignments are made using the MAP command, and they specify the order in which directories--including network directories--are to be searched. This is similar to the way the PATH command operates under DOS, except that the search drives also enable you to work with network directories.
Thus, in the preceding example, if you want to include the network directory SYS:PUBLIC\UTIL as part of the search path, you use these MAP commands:
MAP S1:=SYS:PUBLIC\UTIL
or
MAP INS S1:=SYS:PUBLIC\UTIL
The first MAP command maps search drive 1 (SEARCH1) to the network directory SYS:PUBLIC\UTIL, causing this directory to be searched first. The second MAP command (with the INS option) is similar to the first, but has a subtle difference. The INS option inserts SYS:PUBLIC\UTIL as the first search drive. Inserting means that if the first search drive was assigned previously, it is pushed down the list to become the second search drive, and the later MAP INS S1:=SYS:PUBLIC\UTIL command causes SYS:PUBLIC\UTIL to become the first search drive. This push-down effect is shown in figure 3.31.
Figure 3.31 The push-down effect of using the MAP INS command.
In the preceding figure, the search drives are shown before and after the MAP INS command is issued. Notice that the search drive assignments are pushed down one level after the MAP INS command is issued.
After the MAP S1:=SYS:PUBLIC\UTIL command is issued to map search drive 1, it also changes the DOS PATH environment variable. It does this by assigning an unused drive letter, starting with Z:, to the network directory and inserting Z: in the DOS PATH environment variable. Thus, the DOS PATH environment variable before the MAP S1=SYS:PUBLIC/UTIL command looks like this:
PATH=C:\WP51;C:\BIN;C:\BC\BIN;C:\WC386\BIN
Then, after the MAP command is issued, drive letter Z: is mapped to SYS:PUBLIC\UTIL and inserted in the DOS PATH environment variable, which looks like this:
PATH=Z:.;C:\WP51;C:\BIN;C:\BC\BIN;C:\WC386\BIN
DOS now understands the single letter Z: as another network directory letter and is no longer confused by a directory name such as SYS:PUBLIC\UTIL. DOS searches drive Z: as it would any local drive. The period (.) is a symbol for the current directory and, when used in "Z:." in the PATH environment variable, indicates that the current directory Z: mapped to (SYS:PUBLIC\UTIL) will be searched.
Drive letters for search drives are assigned beginning with Z: and moving up to K:. As an example, search drive 1 is assigned letter Z and search drive 16 is assigned letter K. The reason for the reverse order is that drive letters for applications are usually assigned beginning with drive F: and moving down. This minimizes conflicts in drive letter assignments between applications and search drives.
NOTE: Application drive letters can be safely assigned up to drive J:. If you use drives beyond J: (such as K:), a conflict occurs when you use up the maximum of 16 search drives. That's because search drive 16 also wants to use letter K.This scenario isn't uncommon in complex NetWare user environments. The network manager is sometimes left wishing that the English alphabet had more than 26 letters or that DOS used a different scheme.
Search drive mappings only affect the user's session. That is, if the MAP command is used to map to a network directory, this mapping is only for the user issuing the MAP command. Other users on the network aren't affected. The shell is responsible for keeping the drive mappings for a session. When a user logs out of a server by using the LOGOUT command, the drive mappings are removed from the drive-map table kept by the shell.
The only way to make the drive mappings permanent every time the user logs in is to automate the execution of the MAP commands when the user logs in to the network. One way of doing this is through login scripts.
MAP commands build a network search path by placing them in a login script file. A login script defines a user's network environment. Login scripts are the network equivalent of the DOS AUTOEXEC.BAT file. Login scripts are discussed in detail in Chapter 6, "Customizing the NetWare 4.x User Environment."
PRACTICAL TIP: The most frequently used search drives should be listed first to minimize unnecessary searches. This is particularly true for network search drives, because searching them generates network traffic. Consider an example in which a user needs applications and programs stored in the local drives more often than access to programs on network drives. If the network drives are listed before local drives in the search path, unnecessary traffic is generated while searching for programs in network drives although the program actually resides in the local drives. In this case, the user should have local search drives listed before network search drives.
You cannot map to a network directory unless you have access rights to that directory. Attempting to map to a network directory for which you do not have access rights results in an error message.
If you attempt to map a search drive that is not yet defined, the next logical search drive is assigned as a search drive. Consider the following example, in which a NetWare session has three search drive mappings:
MAP INS S1:=SYS:PUBLIC MAP INS S2:=SYS:PUBLIC\BIN MAP INS S3:=SYS:APPS\BIN
If an attempt is made to perform the following mapping, the next search drive mapping that is assigned is S4: and not S16:
MAP INS S16:=SYS:APPS\DB
This is because search drive S16: doesn't exist, and the next available search drive is S4:. Search drive S16: is typically used for this purpose because it's the last search drive. Any other search drive that isn't used exhibits the same behavior when used in the MAP command. For example, consider if the only search drives that exist are described by the following MAP commands:
MAP INS S1:=SYS:PUBLIC MAP INS S2:=SYS:PUBLIC\BIN MAP INS S3:=SYS:APPS\BIN
Then, using search drive S16: that does not exist, in the following MAP command:
MAP INS S16:=SYS:APPS\WP
maps search drive S4: to SYS:APPS\WP.
Because the last possible search drive in NetWare is search drive 16 (S16:), the MAP INS S16 command is most commonly used to assign the next search drive letter.
The MAP NEXT, or MAP N, command assigns the next available drive as a network drive. Consider the following example, in which only network drive F: has been assigned:
MAP F: = SYS:USERS\JOHN
Then, these MAP NEXT commands:
MAP NEXT SYS:USERS\JOHN\DATA MAP N SYS:DATA MAP NEXT FS1/VOL1:DATA
assign network drive G: to SYS:USERS\JOHN\DATA, network drive H: to SYS:DATA, and network drive I: to FS1/VOL1:DATA, respectively. The second form of the MAP command shows that N is an abbreviation for option NEXT.
After the MAP NEXT command executes, it reports the network drive that has been assigned. The MAP NEXT command is a convenient way to provide network drive mappings using a simpler syntax when it does not matter which network drive is assigned, as long as it is not a network drive that is already in use.
Consider the following MAP command with the ROOT option:
MAP ROOT G: = KSS/VOL1:DEVELOP/BIN
In this command, drive G: is mapped to VOL1:DEVELOP/BIN on server KSS. In addition, specifying the ROOT option roots G: to the network directory KSS/VOL1:DEVELOP/BIN. When a drive is rooted to a network directory, the network directory behaves as the root of the file system. Because the root directory is the top-level directory, one cannot go up the directory by using DOS commands such as the following:
CD .. CD \
The security of the network directory is protected by providing a fake root. A fake root also helps in the installation of single-user applications on the NetWare server. Some single-user applications install in the root directory. If these applications are installed on the server, the root directory on the server volume can become cluttered. A fake root lets the single-user application be installed in a subdirectory on the server.
PRACTICAL TIP: Remember that the only way you can legally install a single-user application on the server is to have a license for as many copies of the single-user application as there are users.
You can abbreviate the ROOT option with the letter R. Thus, the following MAP statements are equivalent:
MAP ROOT G: = KSS/VOL1:DEVELOP/BIN MAP R G: = KSS/VOL1:DEVELOP/BIN
The MAP ROOT command is also useful to overcome the 63 character limitation of the current working directory for DOS workstations that use VLMs.
The MAP NP option enables a local or search drive mapping to be overridden without prompting the user. Its general syntax is as follows:
MAP NP [Option] Drive: = DirectoryPath
Thus, to override the local drive mapping D:, use this command:
MAP NP G: = SYS:USERS/KSS/BIN
To override a search drive mapping for search drive S3 that may already exist, use the following command:
MAP NP S3: = SYS:USERS/DORSH/BIN
PRACTICAL TIP: In NetWare, the CD command alters the drive mapping, so use it with care. Consider what would happen if you used the following command from the local C: drive prompt:C:\> CD SYS:COMMON\DATA
This would map your C drive to SYS:COMMON\DATA. You would then lose access to your C: drive. You can regain access to the local drive C: with the following command:
MAP DEL C:
You would have a similar problem for a network driver as shown next. Consider the situation when Z: is mapped as a second drive to SYS:PUBLIC. Execute this command:
Z: CD\
You'll notice that you have lost your search drive mapping to SYS:PUBLIC. To recover, execute the command:
CD \PUBLIC
The MAP CHANGE option converts a search drive to a network drive.
Consider a network administrator who just installed an application in network drive J: that's mapped to NW4CS_SYS:APPS\WP. The network administrator now wants to test the application by placing it in the search drive. The administrator issues this command:
MAP CHANGE J:
The command also could be given in the abbreviated form, as follows:
MAP C J:
If the next available search drive is S10:, you should see the following displayed as a result of executing any of the previous MAP CHANGE commands:
S10: = J:. [NW4CS_SYS: \]
If you want to remove the search drive and make it a regular drive, you can use the MAP CHANGE to toggle back to the network drive, as follows:
MAP C S10:
Throughout these operations, drive J: still is mapped to SYS:APPS\WP. Even when J: is mapped as a search drive, the association between J: and SYS:APPS\WP is maintained.
One of the most common forms of the MAP command is to use it by itself to display current drive mappings.
If the MAP command is issued without options, you see an output similar to the following:
F:\USERS\KSS> MAP Drives A, B, C, D, E map to local disk Drive F:= NW4CS_SYS:USERS\KSS Drive G:= NW4CS_SYS:COMMON\DATA _ Search Drives _ S1: = Z:.[NW4CS_SYS: \PUBLIC] S2: = Y:.[NW4CS_SYS: \] S3: = C:\BIN S4: = C:\WINDOWS
This MAP output shows that drives A, B, C, D, and E are assigned to local disks. Drive F is the next available network drive and is mapped to NW4CS_SYS:USERS\KSS, the user's home directory. Drive G is mapped to NW4CS_SYS:COMMON\DATA.
The search-drive mappings are listed separately. Search drives S1 and S2 are mapped to NW4CS_SYS:PUBLIC and NW4CS_SYS:\. Search drives S3 and S4 are mapped to C:\BIN and C:\WINDOWS, respectively. The last two search drives are in the following DOS PATH environment variable before logging in to the network:
PATH=C:\BIN;C:\WINDOWS
The network search drive mapping assignments caused these search drives to be pushed down as search drives S3 and S4.
The best way to learn about network drive assignments is to experiment with them. This section gives you steps to follow to test drive mappings.
MAP
The MAP command by itself can be used for examining the current drive mappings. The output for this command appears something like that shown following (the details depend on the way your login script has been set up):
Drives A, B, C, D, E map to local disk Drive F: = NW4CS_SYS:USERS\KSS Drive G: = NW4CS_SYS:COMMON\DATA _ Search Drives _ S1: = Z:. [NW4CS_SYS: \PUBLIC] S2: = Y:. [NW4CS_SYS: \] S3: = C:\BIN S4: = C:\WINDOWS
MAP I:=SYS:PUBLIC
Verify that your mapping has been successful by issuing the MAP command.
MAP J:=SYS:DEVELOP
You should see a message saying that "Directory [SYS:DEVELOP] cannot be located."
MAP J:=SYS:DEVELOP/BIN
If you don't have access permissions to this directory, you receive an error message indicating that the directory is not locatable.
If you understand NetWare file system rights (covered in the next chapter), you might want to perform the extra step of logging in as an Admin user. Assign Read and File Scan rights of SYS:DEVELOP to the user you're working with, and then try to map drive H: to the directory SYS:DEVELOP when logged in as a non-supervisor user:
MAP J:=SYS:DEVELOP/BIN
This time you should be able to perform the mapping successfully.
MAP DEL J:
MAP J:=I:
Issue the MAP command to verify this mapping.
MAP H:=F:\PUBLIC
The preceding command maps H: to the same volume to which F: is mapped, starting from the root and going down to the PUBLIC directory.
Note the current search drives by typing the MAP command, as follows:
MAP
The MAP command displays current drive mappings and search-drive mappings. It might appear similar to the following:
Drives A, B, C, D, E map to local disk Drive F: = NW4CS_SYS:USERS\KSS Drive G: = NW4CS_SYS:COMMON\DATA Drive H: = NW4CS_SYS: \PUBLIC Drive I: = NW4CS_SYS: \PUBLIC Drive J: = NW4CS_SYS: \PUBLIC _ Search Drives _ S1: = Z:. [NW4CS_SYS: \PUBLIC] S2: = Y:. [NW4CS_SYS: \] S3: = C:\BIN S4: = C:\WINDOWS
Notice that the MAP command displays the search drive mappings. In the previous search drive, 1 is mapped to NW4CS_SYS:\PUBLIC.
Now, issue the DOS PATH command to display the current DOS search path, as follows:
PATH
You should see a response that appears similar to the following:
PATH=Z:.;Y:.;C:\BIN;C:\WINDOWS
Notice that the PATH command is consistent with the current search drive mappings.
MAP INS S1:=SYS:DEVELOP/BIN
Examine the changed drive mappings by typing the MAP command. Compare the search drive mappings with those in step 9.
Also, examine the DOS PATH environment variable by typing the PATH command, as follows:
PATH
The results of the PATH command appear similar to the following:
PATH=X:.;Z:.;Y:.;C:\BIN;C:\WINDOWS
Compare the DOS PATH environment variable with that in step 9. Notice that the DOS PATH environment variable has been modified to reflect the changed search driver mappings.
MAP DEL S1:
Examine the new search drive mappings and the DOS PATH environment variable using the commands outlined in step 10. These should have the same values as in step 9.
MAP DEL S16:
If the search drive S16 doesn't exist, trying to delete it produces an error message.
MAP INS S16:=SYS:DEVELOP
Now, examine the search drive mappings by using the following NetWare command:
MAP
Notice that search drive 16 wasn't created. Instead, a search drive was created with a number one greater than the previous search drive. Using the MAP INS S16 command is a convenient trick to add search drives to the end of the current search drive list without having to know the number of the last search drive.
MAP INS S16:=C:\
Examine the new search drive mappings and the DOS PATH environment variable using the MAP and PATH commands. Notice that the directory C:\ is now in the search drive list and the DOS PATH environment variable.
If you do not have a hard drive, you can use floppy drive A:. If you have a diskless workstation, you cannot perform this part of the experiment.
MAP H:=SYS:PUBLIC
Make H: the current drive and use the DOS change directory command to go up one level to the root SYS:, as follows:
H: CD ..
Now issue the MAP command to find out the current search drive mappings.
Notice that the drive mapping of drive H: was changed by the CD command.
Root map the drive H: to SYS:PUBLIC by using the following command:
MAP R H:=SYS:PUBLIC
Make sure H: is the current drive and issue the DOS CD command to go up one level to the root SYS:, as shown here:
H: CD ..
Now, issue the MAP command to find out the current search drive mappings. Notice that, unlike the situation in step 15, the change directory command was not able to go above the fake root.
Try the following command to delete the DOS PATH:
F: CD \ SET PATH=
Now type the MAP command. Unless your current directory is SYS:PUBLIC where the MAP command is kept, you see the following message:
Bad command or file name
Change to the SYS:PUBLIC directory where the MAP.EXE (command program file) is kept by typing the following command:
CD \PUBLIC
Now, type the MAP command. You should see that the search drive mappings have also been wiped out.
PRACTICAL TIP: One trick is that MAP <drive> := will pick up the current working directory and make that a mapped drive.
Because the Volume object is an NDS object, the NDS syntax can be used to refer to the Volume object, regardless of the current context of the user. Figure 3.32 shows an NDS tree for Organization ESL, where the current context is OU=OPS.OU=SALES.O=ESL. The Volume objects CORP_SYS and ENG_VOL are in the contexts OU=CORP.O=ESL and OU=ENGINEERING.O=ESL, respectively.
Figure 3.32 Assigning network drives to Volume objects in an NDS tree.
To create a drive mapping F: to the root of Volume object CORP_SYS, you can use either of the following commands:
MAP F: = .CORP_SYS.CORP.ESL:
or
MAP F: = CORP_SYS.CORP..:
The first version of the MAP command uses a typeless complete name to refer to the Volume object. The second version uses a partial name (relative to the current context OU=OPS.OU=SALES.O=ESL) to refer to the Volume object.
STUDY NOTE: You may be asked questions on which MAP command is legal, given a scenario of a volume with a file system directory structure in an NDS tree.
To map the next available drive (G:) to ENG_SYS using the NEXT option, you can use either of the following commands:
MAP N .CN=ENG_VOL.OU=ENGINEERING.O=ESL:
or
MAP N ENG_VOL.ENGINEERING.ESL..:
The first command uses a complete name with attribute type designators (CN, OU, O) to refer to the Volume object. The second command uses a partial name (relative to the current context OU=OPS.OU=SALES.O=ESL) to refer to the Volume object.
Finally, to map H drive to the OPS_SYS volume, you can use any of the following MAP commands:
MAP H: = .OPS_SYS.SALES.ESL:
or
MAP H: = OPS_SYS:
or
MAP H: = CN=OPS_SYS:
The first command uses a typeless complete name to refer to the Volume object. The second command uses a partial name (relative to the current context OU=OPS.OU=SALES.O=ESL) to refer to the Volume object. Because the Volume object is in the current context, notice you can refer to the Volume object by its common name. The third example of the MAP command is also a partial name, but uses attribute type CN to name the Volume object.
PRACTICAL TIP: The simplest syntax for referring to a Volume object in a MAP statement is if the Volume object is in the current context. If users need frequent access to a Volume object in another context, consider defining an alias to that Volume object in the current context. The users can refer to the volume using a simplified NDS name.
If a Volume object is moved to another location in the NDS tree or renamed (see fig. 3.33), all batch files and login scripts that refer to the old volume position have to be changed. In figure 3.33, the Volume object ENG_VOL is moved from the context OU=ENGINEERING.O=ESL to OU=CORP.O=ESL. Prior to moving the object, the drive K: was mapped to the PUBLIC directory of the ENG_VOL using the NDS path name for the Volume object, as follows:
MAP K: = .ENG_VOL.ENGINEERING.ESL: PUBLIC
Figure 3.33 Moving a Volume object to a different context.
After the relocation of the Volume object name, the previous drive mapping K: is no longer valid. To map drive K: to the PUBLIC directory using the NDS path name, the new drive mapping should be:
MAP K: = .ENG_VOL.CORP.ESL: PUBLIC
To avoid the kind of problems mentioned previously, you need to be able to create a drive mapping that's independent of the position of the Volume object. This can be done using a Directory Map object.
The Directory Map object provides location-independent mapping. This object contains a volume/directory path (see fig. 3.34). Figure 3.35 shows a Directory Map object in the context OU=ENGINEERING.O=ESL. The Directory Map object refers to the PUBLIC directory in the ENG_VOL. To map a drive to the PUBLIC directory using the Directory Map object, issue the following command:
MAP K: = ENG_PUBLIC
Figure 3.34 Directory Map object properties.
Figure 3.35 Location-independent mapping using Directory Map object.
If the ENG_VOL Volume object is moved to the context OU=CORP.O=ESL, the volume/directory path property of the Directory Map object ENG_PUBLIC must be changed, but the mapping to PUBLIC directory does not change.
STUDY NOTE: The Directory Map object can be used to provide location-independent mapping.
Figures 3.36 and 3.37 show further examples of the use of Directory Map objects.
Figure 3.36 Network drive mappings to directories on different volumes.
Figure 3.37 Network drive mappings using Directory Map objects.
Figure 3.36 shows Directory Mappings to different Volume objects. Assume that the current context in the NDS tree is OU=CORP.O=ESL. A drive mapping of I: to the APPS\SS\DATA directory for the Volume object FS1_SYS can be written in any of the following forms:
MAP I: = .CN=FS1_SYS.OU=CORP.O=ESL:APPS\SS\DATA
or
MAP I: = ESL_SYS:APPS\SS\DATA
or
MAP I: = SYS:APPS\SS\DATA
The first version of the MAP command uses a complete name for the Volume object with attribute type designators (CN, OU, O). The second version refers to the partial name of the Volume object, and because the Volume object is in the current context, the common name of the Volume object can be used. The third version uses the physical name of the Volume object and can be used if the user initially connects to the file server FS1.
In the tree branch under the container OU=SALES, a drive mapping of J: to the SHARED\DOCS directory for the Volume object FS2_VOL can be written in any of the following forms:
MAP J: = .CN=FS2_VOL.OU=SALES.O=ESL:SHARED/DOCS
or
MAP J: = .FS2_VOL.SALES.ESL:SHARED/DOCS
or
MAP J: = FS2_VOL.SALES.:SHARED/DOCS
The first form of the MAP command uses a complete name for the Volume object with attribute type designators (CN, OU, O). The second form refers to the typeless complete name of the Volume object. The third form uses the partial name of the Volume object (relative to the current context OU=CORP.O=ESL).
The mappings shown in figure 3.36 can be simplified using Directory Map objects, as shown in figure 3.37. In figure 3.37, two Directory Map objects, CN=Path_Docs and CN=Path_Data, are created. The Directory Map object CN=Path_Docs contains a mapping to the SHARED\DOC directory for Volume object CN=FS2_VOL.OU=SALES.O=ESL, and the Directory Map object Path_Data contains a mapping to the APPS\SS\DATA directory for Volume object CN=FS1_SYS.OU=CORP.O=ESL. The drive mappings of I: and J: in the example in figure 3.36 can now be expressed in terms of the Directory Map objects, as follows:
MAP I: = .CN=Path_Data.OU=CORP.O=ESL
or
MAP I: = .Path_Data.CORP.ESL
or
MAP I: = Path_Data
The first form of the MAP command uses the complete name with attribute types (CN, OU, O) for the Directory Map object. The second form uses a typeless complete name, and the third form uses a partial name for the Directory Map object. Because the Directory Map object is in the current context, the common name of the Directory Map object can be used for the partial name.
The drive mappings for J:, using directory name object, are as follows:
MAP J: = .CN=Path_Docs.OU=CORP.O=ESL
or
MAP J: = .Path_Docs.CORP.ESL
or
MAP J: = Path_Docs
The first form of the MAP command uses complete name with attribute types (CN, OU, O) for the Directory Map object. The first form of the MAP command uses the typeless complete name of the Directory Map object. The third form uses a partial name for the Directory Map object. Because the Directory Map object is in the current context, the common name of the Directory Map object can be used for the partial name.
To create a Directory Map object using the NetWare Administrator, perform the following steps:
You can select the Browse icon, next to the volume and path, to graphically locate the Volume object and the directory you want the Directory Map object to point to.
STUDY NOTE: You may be asked to use a simulated version of NWADMIN to create a Directory Map object.
Figure 3.38 The Create Directory Map object panel.
NetWare provides a number of utilities needed for directory management tasks. Some of the same tasks can be performed by a number of utilities. Tables 3.5 and 3.6 summarize the directory and file management tasks and NetWare utilities that can be performed by them.
Table 3.5 Directory Management Tasks
Tasks | NetWare Utilities |
Move a directory structure | NetWare Administrator, FILER |
Remove a directory and subdirectories | NetWare Administrator, FILER |
Remove multiple subdirectories simultaneously | NetWare Administrator, FILER |
Delete only contents of a directory | NetWare Administrator, FILER |
Create a directory | NetWare Administrator, FILER |
Modify directory information such as creation date, last access date, owner, and attributes | NetWare Administrator, FILER |
View directory information such as creation date, last access date, owner, and attributes | NetWare Administrator, FILER, NDIR |
Rename a directory | NetWare Administrator, FILER, RENDIR |
Copy a directory structure while maintaining NetWare attributes | NetWare Administrator, FILER, NCOPY |
If you are using NWADMIN or FILER to move directories or files from one volume to another, the rights will not be transferred.
Table 3.6 File-Management Tasks
Tasks | NetWare Utilities |
Modify file information such as creation date, last access date, owner, and attributes | NetWare Administrator, FILER |
View file information such as creation date, last access date, owner, and attributes | NetWare Administrator, FILER, NDIR |
Copy files while maintaining NetWare attributes | NetWare Administrator, FILER |
Copy files | NetWare Administrator, FILER, NCOPY |
Salvage/Purge deleted files | NetWare Administrator, FILER |
Set a file or directory to purge upon deletion | NetWare Administrator, FILER |
Files that have been deleted can be salvaged at any time. NetWare keeps a record of the salvageable files in the SYS:DELETED.SAV directory.
The following steps show how salvage/purge operations can be performed using the NetWare Administrator:
Figure 3.39 Salvage options in NetWare Administrator.
Files that are deleted are saved until the user deliberately purges them, or until the NetWare server runs out of unused disk blocks on the volume. If the NetWare server runs out of unused disk blocks before the files are explicitly purged, NetWare deletes the files on first-in, first-out basis.
If you have confidential files, you should purge them after deleting them. You can do this using the NetWare Administrator FILER utility. When you purge deleted files, only the files that you own are removed from the system--unless you have Supervisor file system rights.
STUDY NOTE: Salvage and Purge operations can be performed using the NetWare Administrator or the FILER utilities. The salvageable files are kept in the SYS:DELETED.SAV directory.
For security and space-saving reasons, you might want to purge certain files as soon as they're deleted. You can have NetWare perform this operation for you automatically if you flag the file or directory with the purge attribute. If a directory is flagged with a purge attribute, any file deleted from that directory is immediately purged. You can set the Purge NetWare attribute on files or directories using the NetWare Administrator, FILER, or the FLAG command.
STUDY NOTE: You can set the Purge NetWare attribute on files or directories using the NetWare Administrator, FILER, or the FLAG command.
NetWare 4 has several features for managing space on volumes. Management of volume space consists of the following tasks:
You can display volume space information using the following:
Figure 3.20 (discussed earlier in the chapter) shows the output of the NDIR /VOLUME command. This command displays total volume space, space used by directory entries, space remaining on volume, space available to user running the NDIR /VOLUME command, maximum directory entries, available directory entries, and amount of space saved because of compression.
The same information can also be viewed in a more graphical form using the NetWare Administrator. The following is an outline of using the NetWare Administrator to view volume information:
Figure 3.40 The Volume statistics screen.
When you're running out of disk space, it's helpful to have a report of the files on a volume by their access date, owner, and size. You can use the NDIR command with different options to generate this report. The NDIR command was discussed earlier in this chapter, so only the commands for performing specific tasks are listed here.
To list files not used after some time, use the following command:
NDIR *.* /ACCESS BEF date /S
Replace date with a date, such as 10-1-94.
To list files owned by a specific user, use the following command:
NDIR *.* /OWNER=name /S
Replace name with the user name.
To list files by largest file size first, use the following command:
NDIR *.* /REV SORT SIZE /S
To list files larger than a specific size, use the following command:
NDIR *.* /SIZE GR bytesize
Replace bytesize with the number representing the size of the file in bytes.
NetWare provides you with the ability to manage volume disk space by user or by directory. User space restrictions must be set independently--one each volume. You can use the NetWare Administrator or NETADMIN to restrict disk space for users. Volume objects have a User Space Limits property. This is a multi-valued property to which you can add a user's name and the amount of space he is permitted for that volume.
Figures 3.41 and 3.42 show the User Space Limits property for a Volume object using the NetWare Administrator or NETADMIN. The screens show that users Guest, HACKER, and Jan have restricted space on the volume, and all other users do not have space restrictions.
Figure 3.41 Viewing User Space Limits setting using NetWare Administrator.
Figure 3.42 Viewing User Space Limits setting using NETADMIN.
STUDY NOTE: You can limit the amount of space for a user on a per volume basis using:
- NetWare Administrator
- NETADMIN
You can use the NetWare Administrator or FILER to restrict disk space for a specific directory. This means that the space used by files in the specified directory cannot exceed a certain value. Directories have a Restrict Size property that can be accessed from the Facts page button using the NetWare Administrator.
Figure 3.43 shows the Restrict Size property for a directory using the NetWare Administrator. This figure shows that the directory ETC is restricted to a space of 6400 KB with 6272 KB of space available to it. Figure 3.44 shows the same information using the FILER utility.
Figure 3.43 Restrict Size property for a directory using NetWare Administrator.
STUDY NOTE: You can limit the amount of space in a directory using:
- NetWare Administrator
- FILER
The amount of space a user has is calculated based on the ownership property of files and directories. The user who creates a file or directory becomes the owner. If a user is responsible for copying a large number of files or directories to a volume, that user automatically becomes the owner of the files that are copied. If you do not want the disk space charge to accrue to the user, you must change the ownership of these files. You can change the ownership of a file using NetWare Administrator.
Figure 3.44 shows that there's a Browse icon next to the Ownership property. You can use this to change the ownership of a directory or file.
Figure 3.44 Ownership property of a directory/file.
You can conserve disk space by enabling file compression. File compression is enabled when the volume is created during the server installation. Once enabled for a volume, file compression cannot be permanently disabled unless you re-create the volume.
Whether a file is to be compressed is determined by a number of factors. Files and directories have a number of special attributes that determine the file's compression. For example, if the file is marked with the Immediate Compress (Ic) attribute, the file is compressed immediately. After the compression, the Immediate Compress attribute is reset. You can also set the Don't Compress (Dc) attribute to inform NetWare not to compress a file. The Immediate Compress and Don't Compress attributes apply to files and directories. Another attribute, called the Compress (Co) attribute applies to files only. The Compress attribute indicates whether a file has been compressed, and is a status attribute only.
If the flags do not prohibit compression, the file is compressed--if it hasn't been accessed for a specified time or controlled by a SET parameter that is set on the NetWare server console (SET DAYS UNTOUCHED BEFORE COMPRESSION). The disposition of a file after it's decompressed upon access is determined by a server console SET parameter (SET CONVERT COMPRESSED TO UNCOMPRESSED OPTION). The compression start and stop times are also controllable through SET parameters (SET COMPRESSION DAILY CHECK STARTING HOUR, SET COMPRESSION DAILY CHECK STOP HOUR).
You can also determine if there should be a minimum percentage gain in compression for the compression to take place (SET MINIMUM COMPRESSION PERCENTAGE GAIN). The default for minimum compression percentage gain is 2 percent. You can also control the percentage of disk space on a volume that is required to be free in order for file decompression to permanently change the compressed file to the uncompressed state (SET DECOMPRESS PERCENT DISK SPACE FREE TO ALLOW). This can be used to prevent newly decompressed files from entirely filling up the volume. The time interval between displaying warning alerts--when the file system is not permanently changing compressed files to decompressed files due to insufficient disk free space--is also controllable (SET DECOMPRESS FREE SPACE WARNING INTERVAL).
The file compression attributes for files and directories can be changed using the NetWare Administrator and FILER.
Data migration can be used to transfer inactive files to a near-line storage, with the files still appearing as part of the volume storage. Popular implementation of the near-line storage are optical juke boxes. Data migration can be used in conjunction with previously mentioned techniques to manage space on volumes.
Data Migration is a function of the High Capacity Storage System (HCSS). If HCSS is installed, data migration statistics can be displayed using NetWare Administrator, FILER, and NDIR.
The Don't Migrate (Dm) attribute can be set for files and directories. This attribute can be used to prevent files and directories from being migrated. Another attribute, Migrate (M), applies to files only and is a status attribute that indicates whether a specific file has been migrated.
If you're preparing for the NetWare 4.x Administration exams, review the chapter with the following goals in mind:
This chapter discussed NetWare volumes and directories concepts. You learned about the default NetWare file system structure and how to manage the NetWare file system using tools that come with the NetWare 4.x operating system. You also learned about the NetWare file-system Organization and how to access NetWare directories using the different options of the MAP command.
The following questions can have one correct answer or multiple correct answers. Where a single answer is correct, they are indicated by a l notation that precedes the possible answers. If more than one answer is correct, they are preceded by a n. Some questions are presented in different ways, so that you can recognize them even when the wording is different. Practice quizzes not only test your knowledge, they give you confidence when you take your exam.
A. sharing of data
B. printer sharing
C. access to file storage resources on the network
D. directory replication
A. Unix
B. NFS
C. DOS
D. OS/2
E. Macintosh
A. DOS
B. DOS/MS Windows
C. VMS
D. OS/2
E. IBM's MVS
A. are a logical division of the space available on a server's disk or another storage volume such as a CD-ROM
B. are stored on DOS partition space
C. represent the highest level division of the NetWare file system
D. are limited to a size of 64 GB
A. NetWare volumes are limited to a size of 32 TB
B. NetWare volumes are stored on DOS partition space
C. NetWare volumes represent the highest level division of the NetWare file system
D. NetWare volumes can support DOS, OS/2, and Macintosh name spaces only
A. 32 GB
B. 64 GB
C. 256 GB
D. 32 TB
E. 64 TB
A. 16
B. 32
C. 48
D. 64
E. 128
A. X:
B. CD:
C. NETWARE_40:
D. LONG_VOLUME_CD:
E. MY VOLUME:
A. CN=CORP.O=ESL:PUBLIC\BIN
B. FSC_SYS.CORP.:PUBLIC/BIN
C. FSC_SYS.CORP..:PUBLIC\BIN
D. .FSC_SYS.CORP.SCS:PUBLIC/BIN
E. FSC_SYS:PUBLIC/BIN
F. .CN=FSC_SYS.OU=CORP.O=SCS:PUBLIC/BIN
A. CN=DS_VOL.OU=MKTG.OU=CORP:APPS\DATA
B. DS_VOL.MKTG.CORP:APPS/DATA
C. DS_VOL.MKTG.CORP.:APPS\DATA
D. DS_VOL.MKTG.CORP..:APPS\DATA
E. .DS_VOL.MKTG.CORP.SCS:APPS/DATA
F. .CN=DS_VOL.OU=MKTG.OU=CORP.O=SCS:APPS \DATA
A. CN=NW4CS_VA.OU=LAB.OU= ENG.O=MICROCONN: COMMON\CONFIG
B. .NW4CS_VA.LAB.ENG.MICROCONN :COMMON\CONFIG
C. NW4CS_VA.LAB.ENG.MICROCONN. :COMMON\CONFIG
D. NW4CS_VA.LAB.ENG.MICROCONN.. :COMMON\CONFIG
E. NW4CS_VA:COMMON\CONFIG
A. CN=CORP.O=ESL:PUBLIC\BIN
B. FSC_SYS.CORP.:PUBLIC/BIN
C. FSC_SYS.CORP..:PUBLIC\BIN
D. .FSC_SYS.CORP.SCS:PUBLIC/BIN
E. FSC_SYS:PUBLIC/BIN
F. .CN=FSC_SYS.OU=CORP.O=SCS:PUBLIC/BIN
A. CN=DS_VOL.OU=MKTG.OU=CORP:APPS\DATA
B. DS_VOL.MKTG.CORP:APPS/DATA
C. DS_VOL.MKTG.CORP.:APPS\DATA
D. DS_VOL.MKTG.:APPS\DATA
E. DS_VOL.MKTG.CORP..:APPS\DATA
F. VOL.MKTG.CORP.SCS:APPS/DATA
G. .CN=DS_VOL.OU=MKTG.OU= CORP.O=SCS:APPS\DATA
A. .CN=NW4CS_VA.OU=LAB.OU= ENG.O=MICROCONN: COMMON\CONFIG
B. CN=NW4CS_VA.OU=LAB.OU= ENG.O=MICROCONN: COMMON\CONFIG
C. .NW4CS_VA.LAB.ENG.MICROCONN: COMMON\CONFIG
D. NW4CS_VA.LAB.ENG.MICROCONN..: COMMON\CONFIG
E. NW4CS_VA.LAB.ENG..:COMMON\CONFIG
F. NW4CS_VA:COMMON\CONFIG
A. PUBLIC
B. USERS
C. LOGIN
D. APPS
E. SYSTEM
F. ETC
A. NLIST VOLUME /S
B. NLIST VOLUME
C. NLIST /VOLUME
D. NLIST VOLUME /N
E. NLIST VOLUME /L
A. NLIST VOLUME O=UE /S
B. NLIST VOLUME /S /O=UE
C. NLIST VOLUME /S /D /O=UE
D. NLIST VOLUME /S /CO="O=UE"
E. NLIST VOLUME /S /CO "O=UE"
F. NLIST VOLUME /L
A. NDIR /VOLUME
B. NDIR VOLUME
C. NDIR /STATISTICS
D. NDIR /D
A. NDIR /FO /SORT LA
B. NDIR /FO /SORT SI
C. NDIR /FO /REV SORT SI
D. NDIR /REV SORT SI
A. NDIR SYS:DATA\*.* /Read-Only
B. NDIR SYS:DATA\*.* =RO
C. NDIR SYS:DATA\*.* /RO
D. NDIR SYS:DATA\*.* /ATTR=RO
A. NDIR SYS:*.* /SUB /TRUSTEE EQ KSS
B. NDIR SYS:*.* /SUB = KSS
C. NDIR SYS:*.* /SUB /OW EQ KSS
D. NDIR SYS:*.* /SUB /O EQ KSS
A. NDIR SYS:*.* /SUB /OW NOT EQ Admin
B. NDIR SYS:*.* /SUB /NOT OW EQ Admin
C. NDIR SYS:*.* /SUB /TRUSTEE NOT EQ Admin
D. NDIR SYS:*.* /SUB != Admin
A. NETADMIN
B. NWADMIN
C. FILER
D. UIMPORT
E. DSPACE
A. store directories mapped in the login script file
B. list files in the Directory Map object
C. provide location independent mapping to directories
D. provide location dependent mapping of directories
A. VOL1_EMERALD.LAB
B. EMERALD_VOL1.LAB
C. EMERALD_VOL1.LAB.IAF
D. .EMERALD_VOL1.LAB.IAF
E. .CN=EMERALD_VOL1.OU=LAB.O=IAF
F. .VOL=EMERALD_VOL1.OU=LAB.O=IAF
A. SYS:SYSTEM/DELETED.DAT
B. SYS:DELETED.DAT
C. SYS:SYSTEM/DELETED.SAV
D. SYS:DELETED.SAV
A. NLIST /VOL
B. NLIST /VOLUME
C. NLIST VOL
D. NLIST VOLUME
A. NWADMIN
B. NETADMIN
C. FILER
D. NETUSER
E. PCONSOLE
A. MAP S1=SYS:PUBLIC\UTILS
B. MAP INS S1=SYS:PUBLIC\UTILS
C. MAP S1:=SYS:PUBLIC\UTILS
D. MAP INS S1:=SYS:PUBLIC\UTILS
A. MAP N SALES.SCS:FS2_SYS/PUBLIC/UTILS
B. MAP NEXT SALES.SCS.FS2_SYS:PUBLIC/UTILS
C. MAP N .FS2_SYS.SALES.SCS/PUBLIC/UTILS
D. MAP N .FS2_SYS.SALES.SCS:PUBLIC/UTILS
A. SYS:SYSTEM
B. SYS:LOGIN
C. SYS:MAIL
D. SYS:PUBLIC
A. storing a user's login script files only
B. storing network applications
C. storing private files belonging to user
D. storing common files belonging to all users
A. a directory on the local hard disk or floppy
B. a directory on the search path
C. a directory on a NetWare Volume object
D. a file on a NetWare server
A. MAP S1=SYS:PUBLIC\UTILS
B. MAP INS S1=SYS:PUBLIC\UTILS
C. MAP S1:=SYS:PUBLIC\UTILS
D. MAP INS S1:=SYS:PUBLIC\UTILS
A. MAP DEL N:=FS3/SYS:SHARED\COMMON
B. MAP DEL N:=
C. MAP DEL N:
D. MAP DEL N:\
A. MAP INS N:=SYS:LOGIN\LANFAN
B. MAP INS N:
C. MAP N:=SYS:LOGIN\LANFAN
D. MAP N SYS:LOGIN\LANFAN
A. test the MAP command by faking its operation without performing the actual mapping
B. assign a fake drive to a network directory
C. install an application in a network subdirectory when the application expects to be installed in the root directory
D. install an application in the root directory of a network volume
A. MAP C INS S16:=G:
B. MAP CHANGE G:
C. MAP CHANGE SEARCH G:
D. MAP C SYS:APPS/BIN
© Copyright, Macmillan Computer Publishing. All rights reserved.