CSCI 1730                    Programming Project 3A                  Summer 2009

                       File Sharing with a Child Process


This program is due by midnight on Wednesday, June 24.

The goal of part A of Project 3 is to introduce you to the standard I/O library,
child process creation, and file sharing between parent and child processes. In
part B you will add process control features.  To this end you will create a 
program which reports its own process id and five other identifiers for its
process.  It will do this before and after a call to fork( ). 

Your program should take one or two command line parameters, where the first
is the name of a file to open for writing its reports to.  The optional second
parameter is a flag to indicate whether after the fork the first report should
be written from the parent process or the child process.

An example command line is 

            {odin} forker ofile -c

where "forker" is the name of your executable file and "ofile" is the name of
the file which is to be created.  The process reports are all to be written to
"ofile".  The -c flag indicates that after the fork( ) call the child process
should report before the parent process.  Manage this by having the parent
process sleep for 1 second before reporting after fork( ).  If the flag is -p
then the parent should report first after fork( ); in this case, have the child
process sleep for 1 second after fork( ).  If there is no flag have both the
parent and child processes sleep for 1 second, so that the results of the writes
to "ofile" will be unpredictable.

Each report should contain the six process identifiers listed in the box on
page 210 of the UNIX test.  These should be preceded by "Before the fork: ",
"After the fork (parent): ", or "After the fork (child): ", as appropriate.

Your project submission should include an implementation file forker.c,
a Makefile and a READ_ME file.  Your Makefile should compile forker.c to
the executable file forker using gcc.

Some things to note:

  *The names of the files submitted and of the executable file generated
   by the Makefile must be followed exactly, so that the teaching assistant
   and the instructor can test your project without editing your code.

  *The child process must be created by fork( ), and pauses in execution must
   be implemented by sleep( ).  The fork( ) and sleep( ) system calls are
   described in Chapter 8 of the UNIX text.
	
  *Your program must be written in C.
  
  *All file I/O must be done using the standard I/O library, which is
   described in chapter 5 of the UNIX text.

  *Design your program so that each process terminates normally.

  *Test your "forker" program on various strings for "ofile", including
   legal and illegal file names, and names of files which alreday exist.
   Also test it with no flag, -c as the flag, -p as the flag, and various
   other combinations of command line parameters.  
   
  *The program should be robust and include appropriate error checks.  For
   instance, if in the sample commmand above "ofile" already exists
   then an error message should be issued; if it does exist already, it
   should not be removed or altered.  Any sequence of command line parameters
   which does not conform to one of the three meaningful patters should result
   in an error message followed at once by termination.  That could be too
   many, too few, or a second parameter which is not -c or -p.

  *The submission procedure and requirements common to all projects are
   described on a separate page which is linked from the course "projects"
   sub-page.  Follow the submission procedure carefully.  Note that for 
   submission (as opposed to testing) you must be logged onto "odin".

  *A project which does not compile on "odin", or on "albany" or one of the
   other Linux workstations in the 307 lab, using gcc for GCC 4.1.2, will score
   0.  Projects which do compile properly will be scored out of 100
   (if on time) based on (1) correctness of operation, (2) quality of design,
   (3) coding style and documentation of the source code, and (4) correctness
   and usefulness of the READ_ME file and the Makefile.