NOTE: This assignment, like the other projects in this class, is due at a particular time, listed above. This means that if you are even a minute late, you lose 20%. If you are worried about potentially being late, turn in your project ahead of time. Do this by submitting it electronically before it is due and giving the hard copy to me during office hours or by sliding it under my office door before it is due. Do not send assignments to my personal email address. Do not leave hard copies in my departmental mail box or attempt to give them to departmental staff (who cannot and will not accept them).
In your previous assignment, you took the first step toward the development of a batch image watermarker. However, wm Version 1.0
lacked some functionality we might want in a batch image watermarker, such as the ability to watermark an entire directory full of image files with a single command.
In this assignment, you will take a second step toward the development of a batch image watermarker. This is only a second step, since you have still not learned in this class about mechanisms for passing the input and output of processes to one another (although you will!), and you are not assigned the job of creating a nice GUI front end for your watermarker (since that is a topic for another class). Still, it will let you gain experience with the basic mechanisms for dealing with files, directories, and permissions.
You are to create a program called bwm
to carry out batch
downloading, watermarking, uploading, and verifying steps for single files,
single directories, or directories of directories recursively to any arbitrary
depth. The user will invoke bmw
as follows:
bwm [option] URL WMFILEPATH
Here, URL
may be the URL of a single image file in a common
format, a web page, or a directory, and WMFILEPATH
is the
path to the watermark file. bwm
will determine the type of the URL by its ending, as follows:
.png
, .jpeg
, and .tiff
),
bwm
will behave almost exactly like wm
from Project
2. The one exception is that iff the steps of downloading,
watermarking, and uploading succeed, then bwm
must delete any
temporary files it created during its execution, including the local copy of
the original picture that it downloaded./
), bwm
will treat the URL as a directory and will download all the common image
files (again, at least .png
, .jpeg
, and
.tiff
) in the specified directory, watermark them all with the
same watermark file, upload them all back to the named directory with the
same names as the original images in that directory, and open up the browser
to view that directory. As with the single image file invocation of
bwm
, iff the steps of downloading, watermarking, and
uploading succeed, all temporary files created during execution must be
deleted.‘-r
’
‘--recursive
’Recursively download the common image files in the directory specified by the URL and recursively download the common image files from subdirectories of the specified directory, watermark them all with the same watermark file, upload them all back to the directories in which they were originally found, and open up the browser to view the directory specified in the URL. Recursion should continue up to a depth of five by default. A different depth may be specified along with the option, using the syntax ‘
-r NUM
’ or ‘--recursive=NUM
’. With recursive downloads,bwm
must remove all temporary directories created during execution, as well as all temporary files.IMPORTANT NOTE: When the recursive flag is turned on,
bwm
should wait one second between each download. (Once we have covered IPC, you will also need to wait one second between each upload as well.)
‘There is also one additional exit code that-s
’
‘--save
’Save the original image files (and directories as appropriate) that were downloaded from the remote site, rather than considering them temporary files and deleting them when
bwm
successfully completes the steps of downloading, watermarking, and uploading.
bwm
will use: 5 for failure to delete temporary files and/or directories.
You will turn in both a hard copy and an electronic copy of your assignment. Electronic copies must be submitted to the appropriate drop box in D2L for the course. Do not send them to my email address.
Both the hard copy and the electronic copy will contain a cover sheet
documenting group membership and contributions (see below), all source code
you created for bwm
and a write-up of 1/2 to 1 page (roughly 80
characters per line, 50 lines per page) explaining the data structures and
algorithms used in your code. This page limitation does not include figures
used in your explanations, which are encouraged and may take up any amount of
space. (The explanations do not remove the requirement that your code be well
commented.)
The electronic copy will also contain an executable for bwm
which should be called bwm
.
Your source code must be written in C or C++ and must compile using
gcc
or g++
on the CSN Linux computers. For creating
new processes, changing the executable, and checking on the progress of child
processes, your code must use fork()
, exec
(that is,
any of the exec
family of system calls), and wait
(or
waitpid
), respectively. Your code should be well structured and
well commented. It should conform to good coding standards (e.g., no memory
leaks).
You may write your program from scratch or may start from programs for which the source code is freely available on the web or through other sources (such as friends or student organizations). If you do not start from scratch, you must give a complete and accurate accounting of where all of your code came from and indicate which parts are original or changed, and which you got from which other source. Failure to give credit where credit is due is academic fraud and will be dealt with accordingly.
As noted in the syllabus, you are required to work on this programming assignment in a group of at least two people. It is your responsibility to find other group members and work with them. The group should turn in only one (1) hard copy and one (1) electronic copy of the assignment. Both the electronic and hard copies should contain the names and student ID numbers of all group members. If your group composition changes during the course of working on this assignment (for example, a group of five splits into a group of two and a separate group of three), this must be clearly indicated in your cover sheet (see below), including the names and student ID numbers of everyone involved and details of when the change occurred and who accomplished what before and after the change.
Each group member is required to contribute equally to each project, as far as is possible. Your cover sheet must thoroughly document which group members were involved in each part of the project. For example, if you have three functions in your program and one function was written by group member one, the second was written by group member two, and the third was written jointly and equally by group members three and four, your cover sheet must clearly indicate this division of labor.
Note that all personally identifying information (names, student ID numbers, 4x4s, etc.) must only be included on the cover sheet and nowhere else in the project materials.
For the various functions that your program must carry out, I recommend that
you explore wget
, composite
, and sftp
.
For dealing with directories and files, you may want to
consider the use of mkdir
, opendir
,
readdir
, rewinddir
, closedir
,
nftw
, getcwd
, chdir
,
stat
, unlink
, and/or rmdir
(or related
system calls). More generally, you should look at Chapters 15 and 18 of your Kerrisk textbook.