P0: Getting Started and Moving Files

CEG 433/633: Operating Systems

Download P0.tbz

The project for the current term is to implement (on a simulated disk) a file system based on the design explored in the lectures. This project is divided into four pieces, one piece at a time due every other week or so during the 10-weeks of the term. You must read and follow the Project Expectations. Study the grading sheet given below.

This is Part 0 of the project for this term. You are expected to study and modify the source code files given in P0.tbz and achieve the functionality described below. Do not use source code files of others or even those of mine but from prior terms.

The tar ball P0.tbz is a collection of files given so that (i) you can get started quickly with our project, and (ii) you can see the style of how larger systems programs are written. Download P0.tbz from the link above. In the OSIS Lab, it can be un-tar-ed as follows:

tar xvvfj P0*.tbz

Be Considerate. Do make sure that you are not using up too much space (say > 10 MB) in your home directory. The following will show your disk space usage: du -s ~

1. Learn Unix Commands

Coming into the course, you are expected to be comfortable with Unix commands. Try all the commands of the Minimal List of Unix Commands You cannot claim to be Unix-familiar unless you have used them all a few times. Use script (read man script) to demonstrate that you invoked the commands. A few commands cannot be run unless you are super user; for such commands, just capture its message. Turn this file in as a file named (exactly) cmdsTried.txt.

2. Learn to Use GDB

Coming into the course, you are expected to be comfortable with gdb.

Debugging large programs requires the construction of (extra) observer methods. Using gdb or some other debugger is not as effective as invoking observers and studying their output in a peaceful place ("under a tree"). Nevertheless, gdb can be useful as a last resort, and you must be able to use it well.

  1. Start script. Untar P0.tbz. Make P0 as given. Run our program P0 through gdb.
  2. Set a breakpoint at immediately after setArgsGiven(buf, arg, types, nArgsMax);
  3. Set a breakpoint at the bottom of the SimDisk constructor.
  4. Type in a command to our shell to make a file volume. Trace the execution from the above breakpoint onwards by single stepping (use "next" or "step") until the end of doMakeFV.
  5. Examine the values of buf, arg, types, nArgsMax of setArgsGiven.
  6. End the script. Turn in this script as a file named gdbSession.txt

3 What Is Given

By the time P0 is due, we would have covered the essentials of our File Sys project. The functionality of P0.tbz is described below. Additional details of the code are/were explained in the lectures and in ReadMeP0.txt included in the tar-ball.

fs33% mkfs disknm.dsk

creates an initially empty file volume on the simulated disk named disknm.dsk. The file volume so constructed is the current file volume as used below. If disknm.dsk is not already created, it will now.

The maxfnm, the number of i-nodes, and the i-node height are all given in the diskparams.dat file corresponding to the line for disknm.dsk. The names of 433-files are at most maxfnm characters long. Valid characters in file names are a-z, A-Z, 0-9, hyphen (minus), and period ('.'); all other characters (spaces, slashes, control characters, etc.) are illegal. The height does include the fileSize field.

Here is an example diskparams.dat. Lines starting with # are comments. For clarity, I have lined-up the columns, but the actual diskparams.dat may not do so.

# diskName nBlocks nBytesPerSector maxFnm nInodes iNodeHt
D1             128             512      8      20       3
D2            1024             256     16     100       8
fs33% cp @P0/test0.cpp myfile.txt

copies P0/test0.cpp from your Linux (indicated by the @ sign) current working directory to the current (for now, root) directory of the file volume, as a file named myfile.txt and prints to stdout the i-node number of myfile.txt. If myfile.txt already exists, the new content silently replaces it. In the cp commands, we need to simultaneously deal with path names of files in 433-file-volume and Linux. Only in such cases, the latter are prefixed with the @ symbol.

fs33% cp myfile.txt @P0/test1.cpp

copies myfile.txt of the current file volume to P0/test1.cpp of your Linux current directory and prints to stdout the i-node number of myfile.txt. If P0/test1.cpp already exists, it is silently replaced.

fs33% cp myfile.txt file2.txt

copies myfile.txt of the current file volume to file2.txt of the current volume and prints to stdout the i-node number of file2.txt. If file2.txt already exists, the new content replaces it.

fs33% ls

prints a listing, much like the Unix ls -lisa, of all the files in the root directory of the current file volume.

fs33% rm myfile.txt

remove the file named myfile.txt from the root directory and prints to stdout the i-node number that myfile.txt had. If the file named myfile.txt does not exist, be quiet and print 0.

fs33% inode 4

prints the contents of i-node numbered 4, if it exists, of the current file volume.

In the P0.tbz, there is a stdTestScriptP0.txt. Use it as in ./P0 < stdTestScriptP0.txt.

4. Studying a Program and Improvements

Part of large program development is independently, but wisely, deciding what to do for certain "erroneous" situations. Should we ask the professor for what to do for every possible error you can think of? [Answer: No. You think about it. You take a reasonable action. You document this in your source code, and in ReadMe.txt. And, be ready to defend your choice should it be questioned.] Should SimDisk() constructor printf or cout>> an error message? [No.] How should it deal with parameters so wrong that it cannot construct a simulated disk? [Think.] Remember that one of the goals of CEG 433/633 is to make you think about larger programs. Part of this is to supply missing, but needed, details in the problem description.

4.1 Study the Sources

Study the source code of P0 so thoroughly that you could have written it. Then, answer the itemized questions below in a file named answers.txt.

  1. The following are standard library routines:
    fopen, fclose, fread, fwrite, fstat, fscanf, fprintf, printf, sprintf
    Look up their functionality in both the Stevens' book and the on-line man pages. Describe their functionality briefly, one sentence each, in your own words.
  2. List the names of 5 standard library routines other than the above, and 5 system calls used by the code of P0.
  3. In the file simDisk.cpp, what is the point in verifying that statBuf.st_size == nSectorsPerDisk * nBytesPerSector?
  4. Study the Notes on Programming in C, by Rob Pike. All of it is "very" applicable to C++ also. For five identifiers used in the given source code, (i) either suggest better alternate names and defend why they are better, or (ii) explain why you are comfortable with the names as-they-are.
  5. Write the pre- post conditions for
    uint FileVolume::read33file(byte *fs33leaf, byte *unixFilePath)

    uint FileVolume::write33file(byte *unixFilePath, byte *fs33leaf)

4.2 Robustness

You will find that P0, as given, is "functional" but fragile (not robust). Improve it so that it is crash-proof no matter what inputs are given. Describe the changes you made in a file named improvements.txt. In later project phases, we (you and I) will replace invocations of TODO by working code.

4.3 Adding New Commands

Only the additional elements compared to the given P0 are described below. Add these appropriately to the test script. Our path name syntax is the same as Unix path names. Obviously, not every arbitrary string is a valid path or name. Also, the dot and the dot-dot are not permissible as arguments in some contexts below. Nevertheless these commands must be robust.

fs33% mv da db
The da is either a normal file or a directory. (i) If da does not exist, return 0 and nothing is altered in the file volume. (ii) If db does not exist in the current directory, da is renamed as db. (iii) If db is an existing but ordinary file, delete it and then do as in (ii). For (ii) and (iii) return the i-number of db.

Recall that Unix command mv does two things: (a) when the last argument given is a directory already existing, it moves the files or directories given in the rest of the arguments from where they are into this target directory, or (b) renames the first argument file or directory into the second argument. Look up the man page for more details. Implement (b). Recall that in this P0 we have just the root directory and no subdirectories.

fs33% inode myfile.txt
is an overload of the inode command that the given P0 already has. It first discovers the i-number of file myfile.txt located in the current directory of the current volume and then invokes the original inode command.

4.4 Bugs

In this course, the focus is on OS usage and design -- not on OOP and not on bug-free software engineering. We try to give you credit for your programs even when they are buggy as long as the ideas behind their construction are solid and your program can successfully navigate your own testscript.txt.

The P0 as given has (just) one bug. After removing a file, if we try to do a cp, it fails. (Of course, the cp is given valid arguments). A second attempt succeeds. You will receive 25 "bonus" points if you can pinpoint what causes this problem and provide a fix in the file named bugfix.txt. If you discover additional bugs (we hope not!), describe them also to receive an additional 25 bonus points for all the descriptions.

5. TurnIn

All submissions are done using the turnin program located in /home/ceg433/ceg43300/bin on all the Linux machines in the OSIS Lab. Its first argument is the name of the part of the project, which is uppercase P followed by one digit, e.g., P0. Following this are the names of files that you intend to submit. So, for this part, the command line looks like this:

/home/ceg433/ceg43300/bin/turnin P0 names-of-files-you-wish-to-submit

Grading Sheet for
CEG 433/633: Operating Systems
P0: Subdirectories, and Moving Files

Instructor = Prabhaker Mateti;
Grader = Greg Aselage
Weight 05%
Extra credit points are awarded in recognition of good work and extra work, in addition to the max possible points. Quality is subjectively judged. Merely turning in a file will not receive full score. Some items have a cascading effect.
Student OSIS Login ID Extra credit Points
Item description Max Points
ReadMe.txt exists with content as described in Project Expectations 10 -
Your testscript.txt is designed so that all the functionality is demonstrated, including robustness. 10 -
Your program successfully navigates your own testscript.txt. ( If yours is too simple, we may run it through our script that you will get to see only after the due date.) 10 -
cmdsTried.txt shows use of at least 10 of Minimal List of Unix Commands 10 -
answers.txt 10 -
gdbSession.txt 10 -
Improvement 10 -
mv da db (db does not exist) 10 -
mv da db (db does exist) 10 -
inode printing for both i-numbers and file names 10 -
Fixing the rm bug described above in bugfix.txt B25 -
Discovering additional bugs B25 -
Late submission: minus 2% per day late; Not accepted at all after 4 days -8 -
Files were not submitted using turnin program = minus 10 points -10 -
Total 100 -
-
Copyright © 2009 pmateti@wright.edu