CS 111 Scribe Notes: Lecture 6 (4/15/09)

by Alan Chan and Emily Tran

What can go wrong with files?

1. File Descriptors
   • Use a file descriptor that has already been closed;
   • Close-reopen (use old file descriptor)

     - just like malloc/free, new/delete

   • Leaks can occur when a file is created, but hasn't been closed.

     To check the limit the number of file descriptors for a process, use:

     $ulimit -a

   • Two files may be assigned to the same file descriptor:

     f = open(...);      // file assigned to file descriptor 19
     if (f < 0) error();
     if (close(f) != 0) error();
     g = open(...);      // file descriptor 19 is reused
     close(f);           // calling this will give an errno = EBADF
                         // note that read(f, ...) will also not work

   • More things that can go wrong:

     f = open("foo", O_RDWR); // permissions set to read/write for file "foo"
     read(f,...);
       chmod 444 foo          // user changes permissions of file to read only,
     write(f,...);            // but writing to file will still work since permissions aren't checked
       rm foo                 // user tries to remove file here, but it will remain here until it has been closed
     fork();                  // this will work, but "foo" will not appear when "ls" is called on parent directory

2. Creating a temporary file
   • We don't want it crash with other processes
   • Let's say we have one large file that we split into several smaller ones. We want to sort these small files and then merge them to get back the large one.
     • Problem: There will be multiple sorts running at the same time
     • This raises an issue about the correcness of this method, since results are timing-dependent. The resulting issue is called a race condtion.
   • How do we avoid this problem? Use this OS call:

     f = opentemp(...);

     PROS:

     • Applications don't need to know file location (simpler)
     • OS can put files in a "good" place
     • OS can cache file in RAM
     • OS can rmove files automatically when closed

     CONS:

     • Complexity. We want to minimize system calls, but by doing this, we make 1 more call.
     • Files are "unrelated." Parent/child can't share these files.
     • Operator has difficulty managing runaway processes ("ls" doesn't work)
   • Another way to solve this is to use an unopened file:

     int f = -1;

     do {

     char n[100000];

     close(f);

     create_random_name(n);

     int f = open(n,O_RDRW);

     } while(0 < f) // keep searching for unused (unopened) files to use

     f = open(n, O_RDRW | O_CREAT | O_TRUNC, 0666);

     However, a race condition can occur in the above situation if this program were to run simultaneously with another program that created the same file. Our solution is to replace the above line with this:

     f = open(n, O_RDRW | O_CREAT | O_EXCL, 0666);

     Flags used with open():

     O_CREAT= Create file if it doesn't exist

     O_TRUNC= Truncate the file if it exists

     O_EXCL = Fail if the file already exists. Creates a temporary lock on the directory containing the created file.

• To restrict fila access to only one user or process at a time, we can lock files in the following way:

  fcntl(fd, F_SETLK     // grab lock
            F_SETLKW    // grab lock, wait if necessary
            F_GETLK     // get the first lock which blocks a lock description
                   , p)
      

  Locks are per-process (they are freed when a process exits)

Pipes

Pipes are a bounded I/O buffer. The following command is an example of a pipe being used in the shell. It sorts files and directories in order according to size:

$ du | sort -n

This command equivalent to the following:

$ du > files.list

$ sort -rn files.list

Using a pipe is faster because it runs both commands in parallel. We will not encounter any race conditions with them, and we do not have to use any temporary files to save information.

What can go wrong with pipes?

• Reader, but no writer: the reader will get an EOF
• Writer but no reader ("broken pipe"):

  $ du | less

  Three things can happen:

1. Write hangs.
2. write() returns -1 and sets errno = ESPIPE, but the majority of programs don't chech this exit status.
3. Writer gets signal SIGPIPE and exits.

• Create a pipe, but never use it. This is called a "pipe leak"

Signals

Signals provide a way for asynchronous event handling. The operating system defines a set of signals, each of which are handled differently by the processes that receive them. When a process receives a signal, the operating system interrupts the normal flow of execution, and calls the relevant signal handler.

Signal handling is vulnerable to race conditions. For example, in this case:

signal(SIGPIPE, cleanup);

void cleanup(int p) {

malloc(19);

}

malloc() is not reentrant. That is, it cannot be safely executed concurrently if a second cleanup signal was delivered to a process that is in the middle of executing of the first cleanupsignal handling routine.