Project for the course "Programmazione di Sistema" at Politecnico di Torino
This is the the project 2.1: emergency Back-up proposed by the teachers of the 2nd Italian course.
This emergency backup application offers a way to backup files when the computer screen is not accessible. The user can setup the backup configuration (filters, backup source, backup destination, log file location and more) through a dedicated window or manually via a config.json file. The user will be guided with audio description for the entirety of the process and will be able to abort the backup. The CPU consumption is going to be recorded and written in a log file every 2 minutes, and the backup folder will have a log file too, with total moved bytes and CPU usage.
The back-up can be configurated either by directly modifying the config.json file, or through a dedicated GUI, that will internally fill the config.json file.
As you can see below, you can use the GUI to instruct the utility about:
- which folder(s) to backup
- where to copy the selected folders
- whether to apply some optional filters to the files to backup (see below for details)
- where to place the periodic CPU consumption log
- whether to zip the backup or not
To open the configuration GUI, you need to call the program with option --config (eg. cargo run -- --config or .\target\debug\pds_proj.exe --config)
The config.json file can also be manually edited by the user maintaining the following structure:
{
"dest": "/abs/path/to/dest",
"filters": {
"name": "[^\\.]*\\.c"
},
"logfile": "/abs/path/to/logfile",
"only_last_backup": false,
"src": [
"/abs/path/to/src"
],
"zipped": false
}
You can use filters to customize what files to backup, with great flexibility. You can select the following properties:
- Size filter: you can impose an upper limit and/or a lower limit to the size of the files to backup.
- Name filter: here you can specify a regular expression to only backup files that match it.
- Creation date filter: you can request only to backup files created before or after a certain date, by entering a filter in the format
<dd/mm/yyyyor>dd/mm/yyyy. - Last modified filter: similar to the previous one, but focusing on the last modification date.
- Only modified since last backup filter: only backup files whose last modified date is after the last backup date.
When starting the application without options (eg. cargo run or .\target\debug\pds_proj.exe), you are starting the background job that recognises your backup command.
At this point, you can initiate a backup by moving your mouse according to the first gesture, that is composed of the following steps:
- keep your mouse in the top-left corner for 2 seconds
- draw a rectangle by going down-right-up-left following the border of the screen
After the first gesture is done, an audio message will notify you, explaining how to continue:
- to confirm the backup, move your mouse to the bottom-right corner.
- to abort the backup, move your mouse to the top-right corner.
Alternatively, if you still have the screen available, the confirm/abort command can be given with the window that will popup:
In all cases, further audio messages will notify you of the actions that are being executed, that can be either an abort or a start and end of a backup.
If your computer is connected to multiple screens, the gestures are only recognised if done on the main screen.
The application logs CPU usage every 2 minutes and stores it in a backup_utility.log file, located in the folder chosen when configurating the app.
Every backup folder has a log.txt file. Inside it the user can find the total CPU time used to perform the backup and the total number of bytes copied.
When launching the tool with option --config, the tool automatically adds itself to the programs to launch on system boot.
This will open a black terminal on boot, that is running the utility: keep it opened if you want the tool to work, or close it to stop the program.
The software relies on the cpu_time library to measure the time the CPU needs to dedicate to a specific process. Apparently this library gives a duration of 0 for every duration below 15.625 ms, and sometimes it also gives a result of 0 for durations up to 62.5 ms. For this reason, the durations measured by the program cannot be 100% precise.
To avoid providing wrong data, whenever the program is going to log a value of 0, it is going to write "<62.5 ms", to ensure that the data provided is maybe low-quality, but at least exact.
Unfortunatelly, we were not able to find another library that performed the same task with greater precision, therefore we had to stick with this one.
This project was created by: