System for mainframes has experienced a revival of interest since the GNU/Linux system was ported to run on its virtual engine.
Unix is important, not only for its endurance as the sturdy workhorse of the network, but also for its cultural significance. It has influenced so many other operating systems (including Windows) that further comparisons would be largely redundant. Let us note briefly then, for the record, the basic correspondences between Unix-like operating systems and Windows.
Many basic commands are very similar. Tables 1,2 and 3 give some comparisons between Unix and Windows concepts.
Note: there are differences in nomenclature. What Windows refers to as pipes in its internal documentation is not what Unix refers to as pipes in its internal documentation.
A major problem for Windows has been the need for compatibility with DOS, through Windows 9x to NT. Since both DOS and Windows 9x are insecurable systems, this has led to conflicts of interest. Unix vendors have tried to keep step with Microsoft’s impressive user interface work, in spite of the poor public image of Unix (often the result of private dominance wars between different Unix vendors) but the specially designed hardware platforms built by Unix vendors have had a hard time competing with inferior but cheaper technology from the PC world.
The file hierarchy
The main subdirectories of the root directory together with the most important file are shown below. Their contents are as follows:
• /bin Executable (binary) programs. On most systems this is a separate directory to /usr/bin. In SunOS, this is a pointer (link) to /usr/bin.
• /etc Miscellaneous programs and configuration files. This directory has become very messy over the history of Unix and has become a dumping ground for almost anything.
Recent versions of Unix have begun to tidy up this directory by creating subdirectories /etc/mail, /etc/inet etc.
• /usr This contains the main meat of Unix. This is where application software lives, together with all of the basic libraries used by the OS.
• /usr/bin More executables from the OS.
• /usr/sbin Executables that are mainly of interest to system administrators.
• /usr/local This is where users’ custom software is normally added.
• /sbin A special area for (often statically linked) system binaries. They are placed here to distinguish commands used solely by the system administrator from user commands, and so that they lie on the system root partition, where they are guaranteed to be accessible during booting.
• /sys This holds the configuration data which go to build the system kernel.
(See below.)
• /export Network servers only use this. This contains the disk space set aside for client machines which do not have their own disks. It is like a ‘virtual disk’ for diskless clients.
• /dev and /devices A place where all the ‘logical devices’ are collected. These are called
‘device nodes’ in Unix and are created by mknod. Logical devices are Unix’s official entry points for writing to devices. For instance, /dev/console is a route to the system console, while /dev/kmem is a route for reading kernel memory. Device nodes enable devices to be treated as though they were files.
• /home (Called /users on some systems.) Each user has a separate login directory where files can be kept. These are normally stored under /home by some convention decided by the system administrator.
• /root On newer Unix-like systems, root has been given a home-directory which is no longer the root of the filesystem ‘/’. The name root then loses its logic.
• /var System V and mixed systems have a separate directory for spooling.
Under old BSD systems, /usr/spool contains spool queues and system data.
/var/spool and /var/adm etc. are used for holding queues and system log files.
Every Unix directory contains two ‘virtual’ directories marked by a single dot and two dots.
55
Ls -a . ..
The single dot represents the directory one is already in (the current directory).
The double dots mean the directory one level up the tree from the current location.
Thus, if one writes Cd /usr/share Cd ..
the final directory is /usr. The single dot is very useful in C programming if one wishes to read
‘the current directory’. Since this is always called ‘.’ there is no need to keep track of what the current directory really is. ‘.’ and ‘..’ are hard links to the current and parent directories, respectively.
3.4.2 Windows file model
The Windows operating system supports a variety of legacy filesystems for backward compatibility with DOS and Windows 9x. These older filesystems are insecure, in the sense that they have no mechanisms for restricting access to files. The filesystem NTFS was introduced with NT in order to solve this problem.
The filesystem has gone through a number of revisions and no doubt will go through many more before it reaches constancy. NTFS, like the Unix filesystem, is a hierarchical filesystem with files and directories. Each file or directory has an owner, but no group membership. Files do not have a set of default permission bits, as does Unix; instead they all have full-blooded The NTFS filesystem is indexed by a master file table, which serves an analogous function to Unix’s inodes, though the details are somewhat different.
Filesystem layout
Drawing on its DOS legacy, Windows treats different disk partitions as independent floppy disks, labeled by a letter of the alphabet:
A: B: C: D: ...
For historical reasons, drive A: is normally the diskette station, while drive C: is the primary hard disk partition. Other drive names are assigned at random, but often H: is reserved for partitions containing users’ home directories. Unlike Unix, different devices are not sewn seamlessly into a unified file tree, though this will probably change in a future release of Windows. Originally, DOS chose to deviate from its Unix heritage by changing the subdirectory separator from / to \.
56
Moreover, since each device is treated as a separate entity, there is a root directory on every disk partition:
A: B: C: ... and one has a notion of current working drive, as well as current working directory.
These distinctions often cause confusion amongst users who work with both Unix and Windows.
The layout of the Windows filesystem has changed through the different versions, in an effort to improve the structure. This description relates to NT 4.0. The system root is usually stored in C:\WinNT and is generally referred to by the system environment variable %System Root%.
• C:\I386 This directory contains binary code and data for the Windows operating system. This should normally be left alone.
• C:\Program Files This is Windows’s official location for new software.
Program packages which you buy should install themselves in subdirectories of this directory. More often than not they choose their own locations, however, often with a distressing lack of discipline.
• C:\Temp Temporary scratch space, like Unix’s /tmp.
• C:\WinNT This is the root directory for the Windows system. This is mainly for operating system files, so you should not place new files under this directory yourself unless you really know what you are doing. Some software packages might install themselves here.
• C:\WinNT\config Configuration information for programs. These are generally binary files so the contents of Windows configuration files is not very
interesting.
• C:\WinNT\system32 This is the so-called system root. This is where most system applications and data-files are kept.
3.4.3 Network filesystem models
Unix and Windows have two of the most prevalent filesystem interfaces, apart from DOS itself (which has only a trivial interface), but they are both stunted in their development. In recent years, filesystem designers have returned to an old idea which dates back to a project from Newcastle University, called the Newcastle Connection, an experimental distributed filesystem which could link together many computers seamlessly into a single file tree. To walk around the disk resources of the entire network, one simply used cd to change directory within a global file tree.
This idea of distributed filesystems was partially adopted by Sun Microsystems in developing their Network Filesystem (NFS) for Unix-like operating systems.
57
This is a distributed filesystem, for mainly local area networks. The use of open standards and a willingness to allow other vendors to use the technology quickly made NFS a de-facto standard in the Unix world, overtaking alternatives like RFS. However, owing to vendor disagreement, the Network Filesystem has been limited to the lowest common denominator Unix filesystem-model. Vendor-specific improvements are available, but these do not work in a heterogeneous environment and thus NFS is relatively featureless, by comparison with the functionality available on local disk filesystems. In spite of this, there is no denying that NFS has been very effective, as is testified by the huge number of sites which use it unconditionally.
3.4.4 Unix and Windows sharing
Filesystems can be shared across a network by any of the methods we have discussed above.
We can briefly note here the correspondence of commands and methods for achieving network sharing.
With AFS and DCE/DFS, used mainly on Unix-like hosts, the security model is such that a computer becomes part of a cell or domain. Within such a cell, disk partitions are referred to as volumes. These can be replicated and shared with other computers. AFS cells on other server hosts can be attached to client hosts using the afsd program. A local cell can be published to the rest of the AFS speaking network by adding its attributes to a database. The resulting seamless file tree is visible under /afs. The visibility of files in this model is controlled by the Access Control Lists.
Unix-like hosts use NFS to share filesystems, by running the daemons (e.g. rpc.mountd and rpc.nfsd). Filesystems are made available for sharing by adding them to the file /etc/exports, on most systems, or confusingly to /etc/dfs/dfstab on SVR4 based Unix. The syntax in these files is particular to the flavor of the Unix-like operating system one is using. With some operating Systems, using /etc/exports, it is necessary to run the command exportfs –a to make the contents of the export file visible to the daemons which control access.
On SVR4 systems, like Solaris, there is a command called share for exporting filesystems, and the file /etc/dfs/dfstab is just a shell script containing a lot of share commands, e.g.
allhosts=nomad:vger:nomad.domain.country:vger.domain.country share -F nfs -o rw=$allhosts /site/server/local
Here the command shareall is the equivalent for exporting all filesystems in this file. It simply runs a shell script containing all such commands. The example above makes the directory tree /iu/server/local available to the hosts nomad and vger. Note that due to different name services implementations and their various behaviors, it is often necessary to use both the unqualified and fully qualified names of hosts when sharing.
On the client or receiving end, we attach a shared filesystem to a host by ‘mounting’ it. NFS filesystems are mounted in exactly the same way as they mount
a local disk, i.e. with the mount command, e.g.
58
mkdir -p /site/server/local
mount server:/site/server/local /site/server/local
Here we create a directory on which to mount a foreign filesystem and then mount it on a directory which has the same name as the original on the server. The original name and the new name do not have to be the same, but there is a point to this which we shall return to later. Assuming that the server-host granted us the right to mount the filesystem on our host, we now have access to the remote filesystem, as though it were a local disk. The only exception is the superuser root, who is granted the access rights of a user called nobody. The point of this is that the administrator on the client host is not necessarily the administrator on the server host, and has no obvious right to every user’s files there. This mapping can be overridden if convenience outweighs the minor security it adds.
Windows filesystems on a server are shared, either using the GUI, or by executing the command
net share alias=F:\filetree
On the client side, the file tree can then be ‘mounted’ by executing the command net use X: \\serverhost\alias
This attaches the remote file tree, referenced by the alias, to Windows drive X:. One of the logistical difficulties with the Windows drive model is that drive associations are not constant, but might change when new hardware is detected.
Drive associations can be made to persist by adding a flag net use X: \\serverhost\alias /persistent: yes
to the mount command. This is not a perfect solution, but it works.