Untitled

The aim of this project is to familiarise with the system calls of exec*() family, of fork and low level system calls for file management and bash scripting. We will implement a FileSync System - FSS that will automatically manage the sync of files between directories of source and the respective target, with the capability of watching changes, query management of users and report mechanism. Our implementation should have 1. fss_manager: an App administrator, that should be careful about the structure of sync procedure. 2. fss_console: a user interface for adminstating and submitting queries in the system and 3.fss_script.sh: a helping program (bash script) for reports creating and the clear of old file copies. App of fss_manager and worker processes: Overview of fss_manager:The administrator fss_manager, starts initialised In the system, creating all the necessary communication channels (named pipes). That fulfils the starting sync of the directories and it prepares the watching of the changes (might happen later). Watching directories: The adminstator watches specific source directories for changes, such as creation, edit or deletion. The changes are submitted from worker processes. that run the sync procedures. Accepting new requests: The administator receives new requests for watching directories via communication channels that it has created. Storing info in inner structure: The fss-manager uses data structures sync_info_mem_store (of our choice) for effective search and search of info regarding all watching directories. The sync_info_mem_store (e.g hash table or linked list) stores info per watching directory (e.g source_dir, target_dir, status , last_sync_time, active, error_count). Handling workers limit: If the max allowed number of worker processes is already reached, the administrator puts more workers sync in queue and runs when others are freed. Run of fss_manager: example: ./fss_manager -l <manager_logfile> -c <config_file> -n <worker_limit> where: log file is the recording file of the system. Config file is a file that has directories couple. Particularly each line has a couple (source_dir, target_dir). Source dir has the directory, contents of which will be copied in target_dir. The config_file has the couples source and target directories, gapped with a gap. We assume that source_target dirs are not spanning, meaning there won't be different lines that are sub_directories of other lines. The worker_limit is the max worker limit processes that can be run at the same time (default = 5). Upon starting: The fss_manager in the start creates two named-pipes (fss_in and fss_out) for communicating with fss_console. Then, it prepares the directories watching that are defined in config_file and the sync starts. Particularly, each couple (source_dir, target_dir) in config_file starts a new worker process that will do the sync of two directories and will write that to log file. For simplicity reasons, we assume that the directories are flat and has only files, not subdirectories. If we already reach max worker limit of worker processes, the fss_manager will put more work in the queue and run when a worker finishes. fss_manager commucates via pipes. The fss_manager should use sys calls (inotify_init(), inotify_add_watch(), read(), inotify_rm_watch()) so it can watch directories without creating more processes. The changes that should be watched is only creation, edit,or removing (not moving or renaming). After the watching starts and directory synchronisation the are referred from config_file, the fss_manager is waiting to receive commands via named_pipe fss_in from fss_console. For each command the fss_manager receives it uses it and the output: 1.it sends it back to fss_console via fss_out named pipe and 2.it stores it in manager_log_file. This file is different that console- log - file of the console that will be explained below. Commands the can be accepted from fss_manager. add: <source> <target>: it registers the directory source for watching and immediately starts the sync of its contents in the target directory. Later changes in source are synchronised in real time. Hint: if there is already registered the couple <source,target> for watching sync, it doesn't start sync. cancel <source_dir>: cancel the watching of directory source_dir. status <source_dir>: It returns info for the situation of sync of directory <source dir>, such as last sync time, with any errors that occurred and if it is actively watched or not in the current time. It uses info from sync_info_mem_store. sync<source dir>: it starts a sync of the source dir directory, independently if there are changes or not. The administator starts the search of the target directory in the data structure (sunc_info_mem_store) in its memory. shutdown: it stops the directory watching, waits for the active worker processes to finish, handles the processes of sync that wait in the queue and terminates them smoothly.