Lab3 FAQ

This document contains Frequently Asked Questions, which are relevant to completing the week's lab assignment. Any Questions may be posted to cspp51081.

Where to begin.

For the first week:

• Exercise 3: write filecopy.
     This is the simplest exercise and should be a good warm-up.
     Write a simple make file for making the executable.
• Exercise 2: write filecopy.
     This is long, and will require some research on your part. Use your manual pages.
     Write a simple make file for making the executable.

How Ex3 will be graded.

Your function filecopy should act like the Unix cp command when given two file arguments. This means when we type on the commandline

        filecopy  source   destination

we expect filecopy to behave like cp (You will not implement any of the options of cp.) You will find valuable source code in the lab documentation, as well as in Molay, Understanding Unix/Linux Programming, chapter 2.

Pay careful attention to the following conditions:

• What happens if zero, one or more than two arguments are entered.
• What happens if one of source or target are symbolic links.
• What happens if one of source or target does not exist.
• What happens if one of source or target is a directory.

How Ex2 will be graded.

This exercise is long, and it tests your ability to find information in the manual pages and source header files. Your function my_stat must perform as the Unix command stat. (In what follows I will refer to the C function in italics: stat.) This means we expect that

        my_stat  file

behaves like stat :

• Display the same information, in the same order, in the same way. Try to make your output look like stat, but some deviation is acceptable.
• Behave the same way on each kind of file given: Regular files, directories, symbolic links, files with special permissions (set user enabled or the sticky bit enabled.)
• Re-act similarly to error conditions: no argument given, multiple arguments given, arguments which are not files.

Help!!: How to do Ex2

This is an exercise in your resourcefulness in finding information. Start with the unix manpages for stat and stat (see previous FAQ message for the distinction.) The key to implementing this project is struct stat found in /usr/include/sys/stat.h: everything you need to implement stat is found in this structure. The challenge is to extract this information and displaying it. The manpages will give you useful macros and auxillary functions for doing this. In addition, I have found the following two sources very helpful:

• Molay, Understanding Unix/Linux Programming, pp. 82-90
• Stevens, Advanced Programming in the Unix Environment, Chapter 4.

How to print the device number for my_stat.

The Unix command stat prints the following data for /dev/ttysf (a special charcter file for a terminal)
        Device: 301h/769d
The information here comes from the struct stat element st_dev and the two values are the hexidecimal representation (301) and decimal representation (769) of st_dev. Armed with this knowledge you should have no problem printing this line
        printf("%10s %xh/%dd\t", "Device:", buf.st_dev, buf.st_dev);
Not so fast. You will get the following output:
        Device: 301h/0d
What has happened? The type of st_dev is dev_t, so what in the world is this? A search of the header file /usr/include/sys/types.h (a required header file to use stat) led me to the following
        typedef __dev_t dev_t;
(not too helpful). Following the scent I went to the header file /usr/include/bits/types.h, of sys/types.h and found the following:
        typedef __u_quad_t __dev_t;      /* Type of device numbers. */
        typedef unsigned long long int __u_quad_t;
So, dev_t is really of type unsigned long long int. This is no stutter, a couple of years ago C extended its types to include 64-bit integers, and Linux has chosen to use this type to to code the device number. (Not all machines have 64-bit integer types and not all compilers recognize this type--although gcc does--so you will find an alternate definition of __u_quad_t as a struct consisting of an array of two unsigned long integers. This is just a piece of kluge.)

To use printf to print such a value you will use a modifier: ll (i.e. long long) and the type u (unsigned)
        printf("%10s %llxh/%llud\t", "Device:", buf.st_dev, buf.st_dev);


See Molay, Understanding Unix/Linux Programming, pp. 131-4 (for filesystems--which are the location given by st_dev, for regular files and directories) and pp. 140-5 (with special files where st_dev give their location in the actual code the kernel uses to service these devices.)

Test my_stat on an assortment of files.

You will want to test my_stat on a number of different kinds of files, and permissions, to make sure it works properly. These are the kinds of test we will run on your command. Here are some files I found on on the Department's server:

• For character special (mainly terminals which read and print characters) and block special files (mainly storage devices which read and print to blocks), you will find many choices in the directory /dev.
• Pipes are hard to find (you will be creating your own shortly) since they generally aren't around long, but one which is permanent is /dev/xconsole. I believe this is a pipe which sends commands executed from the X Window console to the shell for processing.
• For an example of a socket, try /dev/log which is a socket to the department's data file passwd and accessed when you log-on. Recall, that ypcat passwd connected you to this network when you were looking for 'John's.

Device Numbers for Special File types

Character special files and Block special files are really device drivers, they are typically parts of the kernel code. Stat displays a special field for these files: "Device type" which displays two values:

      "Device type: a,3"

These values are given by the structure element st_rdev and can be accessed using two special macros: major , minor. They are printed in hexadecimal notation:

maj = major(buf.st_rdev);
min = minor(buf.st_rdev);
printf("%11s: %x,%x", "Device type", maj, min);

Twelve Permission Bits of Mode

The structure element st_mode consists of 16 significant bits: The first 12 are for permisions the last four are for the seven file types. You know about the first nine permissions: 'r','w' and 'x' for the user, group and everyone else. The last three are special access permissions: set-user, set-group and the sticky bit. Molay, Understanding Unix/Linux Programming (pp. 91-7) is a very good reference. These permissions can be set using the Unix command chmod:

• chmod u+s will set the set-user permission: The set-user permission allows the owner of the file to set the rules for changing the file, by giving everyone access to the file only through a user defined command. For example, /usr/bin/passwd often has this permission set to allow a user to modify this file if to change their passwd, but not to be able to modify anything else.
• chmod u+g will set the set-group permission
• chmod o+t will set the sticky bit, but this is only meaningful for directories. For example, /temp is a directory with the sticky bit set. Many people will write to this directory (when they want to create temporary files), but only those who own the file have permission to remove their files.

Running a Program from a Shared Library

Many people have correctly built their shared library, libmylib.so, and linked their program, myprog, to the library using make, but then find they cannot run their program: the loader complains it cannot find the library libmylib.so, or that the functions myprog uses from the library cannot be found. The problem is that the loader searches for libraries in predefined directories. This search is set in the shell environment variable LD_LIBRARY_PATH. You will need to be sure this is set to your current directory, or whatever directory your library is located.

LD_LIBRARY_PATH=/full/path/to/library/directory:${LD_LIBRARY_PATH}
export LD_LIBRARY_PATH

Here /full/path/to/library/directory can be just ., for your current working directory.