One of the changes in Cedar 5.0 is that it uses a user profile entry to decide what DF files to bring over during booting. The boot looks in your user profile for an "Installation.Bringover" entry, which can be any list of DF Files; only the exported components of these DF files are fetched.

What if you're just getting started and don't even have a user profile on your local disk? In this case, the booting machinery will try to find a user profile in a reasonable place. First, if you have a directory on Ivy, it will be searched for a <UserName>.profile; if this fails, then the default profile is taken from [Indigo]<Cedar>Top>User.Profile.

You cannot boot Cedar 5 correctly with a Cedar 4.4 user profile. So, if you have an old profile stored on [Ivy]<UserName>UserName.profile, you should either

There have been a large number of changes in the user profile options for Cedar 5, so if you plan substantial modification of the default profile, look in [Indigo]<Cedar>Documentation>UserProfileDoc.tioga first.

One of the major changes that you will see after you boot is that many more files seem to be on your disk than you are used to in Cedar 4.4. (Type `List *Doc.tioga' in a CommandTool to see how many more documentation files there are!) No, your disk hasn't gotten bigger nor has Cedar become greedy and left you with no room to work. Instead, the DF software has made use of FS attachments to give local names to many of the files stored on [Indigo]<Cedar>. To explain what this means, you need to know something about the way FS names files.

Names for FS files are called ``FNames.'' An FName consists of (in order) a server, a root directory, zero or more subdirectories, a simple name, and a version. Both FTP bracket syntax and CIFS slash syntax for FNames are accepted; the following constructs are equivalent:

A named server like [Ivy] or /Indigo/ is a remote file server. The names of files on remote servers are called ``GNames,'' for global names.

An unnamed server, [] or //, means the local server (your disk). The names of files on the local server are called ``LNames,'' for local names.

In a GName, the rootDirectory is the directory on the server.

In an LName, the rootDirectory is the name of the partition. []<> or /// means the current partition. For example, if you are in the Debugger partition, ///foo.mesa means the foo.mesa file in the Debugger, while //Cedar/foo.mesa means the foo.mesa file on the Cedar partition. (So you don't need the ClientFileTool anymore.)

All FNames, both GNames and LNames, have version parts. For example, the following are complete FNames:

An attachment in FS is an association of an LName to a GName; for instance, after you boot there will be an attachment from ///WalnutDoc.tioga!1 to [Indigo]<Cedar>Documentation>WalnutDoc.tioga!H. When you do a Bringover, the only effect is to establish the attachments of the local names to the global names -- no copying of the contents of any of the global files is done. Attachments are cheap in FS, making it possible to have many LNames in your local file system without giving up all your disk to the system.

An FName that does not start with a server part is called a partial name and will be interpreted relative to a working directory. If you type a file name in a CommandTool, it will be interpreted relative to the working directory that appears in the CommandTool herald line; the default is ///, pronounced root. Working directories aren't fully implemented in Cedar yet, but if you'd like to get some idea of how they will be able to help you in the future, go read Cedar5LocalDirectories.tioga.

When you open a file using an LName that is an attachment to a GName or if you open a file using a GName directly, FS has to copy the bits of the file from the server to the local file cache. Because of this copying, you will often see some delays when you open a file; in the worse case the open may fail because the server is dead. This is the price you pay for keeping things remotely and leaving your local disk uncluttered.

Another effect of the caching is that your disk space (as measured by Watch) will normally hover around 1000 free pages. That sounds like a small amount, but it really isn't. Most of the space on the disk is being managed by the FS cache; if you need space, the FS cache manager can allocate space to your local files by removing from the cache files stored on remote servers.

Because all file names now have explicit versions, Tioga no longer produces a $ file when you save a file you have been editing. Instead, it makes a new file with the next higher version number. The default in Cedar 5.0 is to keep at most two versions of each .tioga file, so the previous version will be not be destroyed.

Most of the time a version number is not necessary as part of an FName -- FS will use either the most recent or least recent version as is appropriate. You can name a particular version of a file by using either a version number or the version variables !L, meaning the lowest existing version number, or !H, meaning the highest existing version number. The most recent version of Foo.tioga is Foo.tioga!H and (using the default of keeping two versions) the previous version is Foo.tioga!L.

The DFDisk program no longer exists. Instead, the -u (unbackedup) option of the list command will list only those files that are not FS attachments, meaning that they are not backed up anywhere. If the current working directory is root (///), then `List -ur *!H' gives a list equivalent to the [Unknown]<Unknown> entries produced by DFDisk (the r switch forces '* to match '/ and '>, so subdirectories will be searched). Note that List -u * means List -u *!*, which will likely also include unbacked-up old versions of files (which you probably don't care about).

To get a new CommandTool, click ``Cmd'' in the upper right hand part of the screen. CommandToolGuide.tioga gives a general introduction to the use of the command tool. The CommandTool gives you a much more limited set of buttons than you used to have with the UserExec. To set a breakpoint, for instance, you need to use the InterpreterTool.

To get a new InterpreterTool, type ``Interpreter'' to a CommandTool. InterpreterToolDoc.tioga gives a general introduction to the use of the InterpreterTool.