CSCI1730 - Breakout - Lab 07 - Solved

Remove - AKA, Be Careful and Do Not Accidentally Delete Your Odin Account



Problem / Exercise
For this lab, you will implement your own version of the rm systems program, a standard Unix utility that attempts to remove files or directory files using the unlink(2) and rmdir(2) system calls. If the permissions of the file do not permit writing, and the standard input device is a terminal, the user is prompted (on the standard error output) for confirmation. The command-syntax is:

$ ./rm [-rf] file...

Your implementation should match the output of the existing rm utility. The -r option causes rm to attempt to recursively remove the file hierarchy rooted in each file argument (see opendir(3), readdir(3), and closedir(3)). If the user does not respond affirmatively, the file hierarchy rooted in that directory is skipped. The -f option causes rm to assume affirmative responses from the user, foregoing any prompting.

Take special precautions NOT to recurse on the .. directory entry. Also think carefully on what you want to do with the . directory entry. If you are concerned, backing up important files on your odin account before testing your code may be a good idea.

You are NOT allowed to use the exec, system, popen, and pclose system calls or functions in your implementation. You are not allowed to call the existing rm implementation. You must supply your own implementation that uses low-level file I/O (APUE Ch. 3), if needed.

The system calls and C library functions needed to complete this lab may not be explicitly discussed in class. You may need to read the manual pages or look up in the textbook/online on how to use certain system calls and C library functions.


2           Some Nonfunctional Requirements
Your submission needs to satisfy the following nonfunctional requirements:

•    Directory Setup: Make sure that all of your files are in a directory called LastName-FirstName-lab07, where LastName and FirstName are replaced with your actual last name and first name, respectively.

•    Libraries: You are allowed to use any of the C standard libraries. When reading or writing to a file are concerned, you need to use low-level calls to read(2) and write(2) and related functions. You are NOT allowed to use the following system calls in any of your implementations: fork(2), execve(2), exec(3), popen(3), and system(3) (or related functions).

1

•    Unbuffered Output: Whenever possible, program output should be unbuffered. The best way to guarantee that output is unbuffered (i.e., characters at the destination as soon as possible) is to directly call write(2).

•    Documentation: Your code must be documented using Javadoc style comments. Use inline documentation, as needed, to explain ambiguous or tricky parts of your code.

•    Standards & Flags: Make sure that when you compile, you pass the following options to gcc:

-Wall -pedantic-errors

Other compiler/linker options may be needed in addition to the ones mentioned above. The expectation is that the grader should be able to type make clean and make in the following to clean and compile/link your submission, respectively.

•    README File: Make sure to include a README file that includes the following information presented in a reasonably formatted way:

–    Your name and UGA ID (811#).

–    Instructions on how to compile and run your program.

•    Compiler Warnings: Since you should be compiling with both the -Wall and -pedantic-errors options, your code is expected to compile without gcc issuing any warnings.

•    Memory Leaks: Since this assignment may make use of dynamic memory allocation, you are expected to ensure that your project implementation does not result in any memory leaks. We will test for memory leaks using the valgrind utility.