4.9 KiB
slug | title | description | last_update | ||
---|---|---|---|---|---|
garbage_collect | Practice exam B | Garbage everywhere… |
|
Garbage Collection
:::warning Exam environment
- During the exam you will be provided with a barebone exam session on the faculty computers.
- In browser you are only allowed to have the following tabs open:
- C documentation
- page containing the assignment
- You are not allowed to use your own source code, e.g. prepared beforehand or from the seminars.
- You have 5 minutes to read through the assignment and ask any follow-up questions should be there something unclear.
- You have 60 minutes to work on the assignment, afterward your work will be discussed with your seminar tutor.
:::
You have gotten into a trouble during your regular upgrade of your archLinux1 installation… You've been carelessly running the upgrades for months and forgot about clearing up the caches.
Your task is to write a program garbage_collect
that will evaluate the shell
history provided as a file and will try to find files or directories that are
suspiciously big and decide which of them should be deleted to free some space.
Format of the shell history
You are provided one file consisting of the captured buffer of the terminal. You can see only two commands being used:
-
cd ‹somewhere›
that changes the current working directory.At the beginning you start in the root of the filesystem (i.e.
/
).You are guaranteed that
‹somewhere›
is:.
that is a current working directory (i.e. does nothing),..
that moves you up one level (in case you are in/
, does nothing), or- is a valid directory in the current working directory.
:::warning[caution]
There are no guarantees or restrictions on the names of the files or directories!
:::
-
ls
that will list files in the current working directory and their respective sizes. If there is a directory in the current working it hasdir
instead of the size.
$ ls
dir a
14848514 b.txt
8504156 c.dat
dir d
$ cd a
$ cd .
$ cd .
$ cd .
$ ls
dir e
29116 f
2557 g
62596 h.lst
$ cd e
$ ls
584 i
$ cd ..
$ cd ..
$ cd d
$ ls
4060174 j
8033020 d.log
5626152 d.ext
7214296 k
For this input, you will get following file system:
- / (dir, size=48381165)
- a (dir, size=94853)
- e (dir, size=584)
- i (file, size=584)
- f (file, size=29116)
- g (file, size=2557)
- h.lst (file, size=62596)
- b.txt (file, size=14848514)
- c.dat (file, size=8504156)
- d (dir, size=24933642)
- j (file, size=4060174)
- d.log (file, size=8033020)
- d.ext (file, size=5626152)
- k (file, size=7214296)
Format of the output
Your program should support 2 switches:
-gt ‹min_size›
that will print out suspiciously big files.-f ‹total_size› ‹min_unused›
that will print out a file to be deleted.
-gt ‹min_size›
With this switch you are provided one additional argument:
min_size
that is the lower bound (inclusive) for size of any file or directory that is supposed to be listed.
When your program is being run with this switch, it is is supposed to print out
all files and directories that are bigger than the provided min_size
.
-f ‹total_size› ‹min_unused›
With this switch you are provided two additional arguments:
total_size
that is a total size of the filesystem2.min_unused
that is a minimum of free space required for an upgrade.
Your program should find exactly one file or a directory that is of the smallest size, but big enough to free enough space for the upgrade to proceed.
In other words, if that file or directory is deleted, following should hold:
\mathtt{total_size} - \mathtt{used} \geq \mathtt{min_unused}
Example usage
You can have a look at the example usage of your program. We can run your program from the shell like
$ ./garbage_collect shell_history.txt -gt 10000000
24933642 /d
14848514 /b.txt
48381165 /
$ ./garbage_collect shell_history.txt -f 70000000 30000000
24933642 /d
Requirements and notes
- Define structures (and enumerations, if applicable) for the parsed information from the files.
- For keeping the “records”, use some dynamic data structure.
- Don't forget to consider pros and cons of using specific data structures before going through implementing.
- You are not required to produce 1:1 output to the provided examples, they are just a hint to not waste your time tinkering with a user experience.
- If any of the operations on the input files should fail, you are expected to handle the situation accordingly.
- Failures of any other common functions (e.g. functions used for memory management) should be handled in the same way as they were in the homeworks and seminars.
- Your program must free all the resources before exiting.