In D-machine Cedar, there was your local file system and there were file servers. You got the two confused at your peril. Mostly by using the DF software, you built attachments to files on file servers in the local name space of your machine's file system. Files created in your local file system would be lost if they were not pushed out to a file server (e. g., by SModel).

In PCedar, there is no local file system. All files exist on file servers (Not strictly true: for a particular SUN you can use the local file system. This creates grief for backup, you can work only on your SUN, and if you do this you shouldn't be reading this, but should have wrote it). The file servers currently are all NFS servers. NFS stands for Network File Server. It is a protocol built by SUN to give access to UNIX file systems remotely. NFS is extremely well established as the file server protocol of choice for lots of vendors. We have three different NFS products in the building right now: SUNs, a 6 Gigabyte (to become 12 gigabyte) MIPS Co. server (gharlane), and a magnetic/optical disk server from Epoch.

There are the concepts of a local directory and a remote directory. These are just conventions: they both are really on file servers. A local directory is a place to do bring-over's (well, qbo) into and smodel from, while the remote directory is a place to do bring-over's from and smodel to. The term working directory is interchangeable with local directory for this document.

NFS filing has two principle flaws for PCedar (for the casual user). It does not have versions and it does case sensitive file name lookups. To get around these problems, when files are written (say by SModel) to an NFS server, from either Cedar or PCedar, two files are written. One is the file with the contents, the other determines the case. Let's look at a particular file:

There are several versions of the file. The ".~3~" extension (pronounced "bang three") tells the system what version this file is. For all of the CountedVMImpl.mesa files, there is one "case" file. It is has the prototype casing for the files. It is preceded by a ".". Using the UNIX "ls" command, files with a leading "." are not normally listed (use the -a switch to see them).

The twiddle processing is only done for file names. Directories do not have twiddles, but they have case files if they are remote directories. Local directories do not have case files and are interpreted literally, as they are cased. If you create a directory as a side effect of writing a file in the Cedar view from a D-machine, then the directory will have a case file. For example from D-machine Cedar:

From Cedar (and sometimes from PCedar, but not always yet) all of this junk disappears and the name you expect, CountedVMImpl.mesa!3, is the name seen. Unfortunately, there is a lot of processing (e. g., type "ls /PCedar2.0/Top/Aardvark*" and watch the CPU pin for half a minute on a Dorado) that has to be done to provide this fiction, so things can be very busy and very slow, particularly in big directories (e. g., /PCedar2.0/Top).

From Cedar, there are two "views" of the file system: the "Cedar" view and the "UNIX" view. Cedar can tell which view you want by looking at the suffix of the server name: "NFS" means the Cedar view and "UX" means the UNIX view. The Cedar view does all the mappings described above. It does case insensitive name matching, even in directory names. The UNIX view gives the raw file names with the "~"'s and "." When using the UX view, case in names is very important. The PCedar interface UFS also uses the UNIX view. So, the current PSeudo server in Cedar for Cedar7.0 is

So, typing "list" to Cedar of [Cedar7.0]<SafeStorage>CountedVMImpl.mesa gives

But:

However, getting the case "wrong" can cause trouble:

The "noent" error means that there is "no entry" for that name. That is, the name does not exist.

The case files are (sometimes?) required for files and directories to be "seen." Files or directories without case files can disappear from the Cedar view.

Going back to file server directories and working directories, file server directories have all the case files and have twiddled file names. Files in working directories, (constructed by, for example, qbo) have non-versioned, correctly cased file names. For example, after doing a PCedarSetUp in PCedar, a directory path is constructed of Cedar/2.0/System and a file is constructed in your local file system called PCedarTools. (The "ls" command in UNIX, with our default aliases (we use the -F switch), prints suffix characters to indicate something about the file. PCedarTools actually will print as "PCedarTools*" inside of UNIX, with the "*" meaning that it is an executable file.) The file really, really is called PCedarTools; there are no case or twiddled names around.

Many tools demand correctly cased, non-twiddled names. REdit only works with correctly cased, non-twiddled names. DF files are almost required for everything in PCedar so that the casing is right. PSeudoServers do not work with some commands in PCedar (e. g., ls). In PCedar, "del filename" does not work but "del filename!*" works.

File names can be quite long. There is a 1K restriction on the size of NFS file names. The names are inconvenient for printing, but are not close to the 1K restriction. For example:

One other interesting detail is that qbo really moves bits. It does not just make an "attachment" (a link in UNIX terminology). The new file actually has the proper create time, so SModel can use the time as the unique ID to detect modification and hence the necessity to write the file back. One consequence of this is that qbo's can be slow (they schlep the bits) and take up room. Unlike D-machine Cedar, it is good practice to delete all the files from a local directory when you are done. Currently, the "delete" command in PCedar Commander likes having a "!*" suffixed after the file name you are deleting (e. g., "% del Foo.mesa!*"). "du" is a good UNIX command for finding disk usage.

File servers are computers. They are named through a naming protocol called "Yellow Pages." For the purposes here, we think of these mappings as mapping a file server name, such as Nadreck, to the network address of that server. There are other uses of Yellow Pages.

A file system corresponds to a disk on a file server (it can be part of a disk too). Files are completely contained in a file system. (Hard links are not permitted between file systems, but symbolic links are fine between file systems.) So, the first few parts of a file name are (usually) the server name and the file system name. [Nadreck-UX]<gris> (a Cedar name) is the name of a file server and file system. So from Cedar:

When invoking names from PCedar, different conventions apply. The same name has to preceded by /net, forget about the -UX and -NFS, and get the casing right. So, from UNIX:

To use a file system, it has to be mounted. Essentially, this makes the file system name known. Traditionally, all file systems on a UNIX machine were just mounted as part of booting. Things got more complicated in a network environment.

This is the abstract from Brent Callaghan's and Tom Lyon's USENIX Winter '89 conference paper "The Automounter".

So, when a file system is referred to, and it is in the list of file systems to automount, it is automatically mounted. We automount a pseudo file system called "/net" from which all of the file systems in all of our file servers are known. When automount occurs, it mounts "/net" under the pseudo mount point of "/tmp mnt". That is slash-t-m-p-underscore-m-n-t -- an underscore prints like "←" in this font, so I've represented it here so it looks proper here. The actual characters are "/tmp←mnt" -- which will be used from now on. You'll see the underscore in typescripts in most cases since Ascii.style is used in typescripts, and the back arrow in the viewer title of REdit (for example).

My (Hagmann's) home directory is on palain. It's actually directory "hagmann" in file system "palain" on the server "palain". (Some of our file servers, at lease palain and nadreck, have file systems with the same name as the server!) When someone name's file system "palain", it gets automounted through the "/net" automount name, so:

Some machines apparently mount file system palain, so they just have:

We also automount file systems (as opposed to file servers). These are done through the /volume automount. So you will see names like:

Notice how sometimes that there are two (or more) slashes in a row. UNIX interprets these as one slash.

Directories in D-machine Cedar and on IFS's were just a fiction: games were played with the file name. Directories in UNIX are real. They are not always automatically created as needed. So you usually have to make them before doing work. Currently, the only way to make a directory in the UNIX world is to use the UNIX shell "mkdir" command (from D-machine Cedar doing, say, and SModel, directories will be created for you as needed (I think)). It is likely that a command tool command version mkdir will appear shortly.

By the way, to get rid of the directory, first empty it (in the UNIX shell, use the "rm" command for files and "rmdir" command for directories) and then use the rmdir command.

So, suppose that you want to work on FooImpl inside of Bar.df. Type (in a UNIX login shell):

You now have a viewer on your Dorado screen for FooImpl.tioga.

Let's go through this line by line.

Always use DF files. By getting the working directory set up correctly, the tools will work (if they are going to work at all). DFPorter can help you migrate old DF files to PCedar.

Use the working directory. "cd" yourself to where you want to be, and then use the tools.

Use mkdir. Whenever things don't seem to work, worry that you forgot to make a directory. mkdir is a Unix comman, however, it also works from Cedar.

Delver. Clean up directories.

Be patient. Many things will be fixed with time. Yellow page servers will be slow. UNIX directories are stored as a heap. They have to be scanned linearly to do most operations. Big directories are slow.