Devlog #9: FileSystem Events

I’ve been spending some time reworking and polishing the logic and database schemas that allows the OS to monitor changes made to WatchedFolders through the FileSystemWatcher class.

Handling FileSystem Events

Here’s the current rundown of how my program monitors for filesystem events (e.g. file created, deleted, renamed, moved, or changed)

filesystem event
    -> record the change in a database queue
    -> return

When a scheduled backup runs, the program reads the queue and the associated changes made to each file/folder, and then updates the corresponding item in the cloud.

scheduled backup
    -> read queued changes
    -> check whether the file still exists
    -> wait/retry if it is locked
    -> upload the latest version
    -> remove the queue item/mark as complete

I’ve also made edits to the OnFileRenamedEvent() to differentiate between renames and moves, which both use the “Renamed” event.

---

PendingSyncItem

This will be a SQLite table that stores pending sync actions upon being handled by the event handler.

The PendingSyncItem works in a simple way for both files and folders. It tracks five types of boolean events props in terms of cascading importance. Multiple event props can be true.

1. Deleted - the most important event prop. If this prop is true, all other event props are skipped (as they matter not if the file was deleted). A deleted API request will be sent to the corresponding REST API.
2. Moved - creates the file if the file did not previously exist. References the string OriginalLocalPath.
3. Renamed - sends a rename API request.
4. Changed - finds the existing file in the cloud and updates the file.
5. Created - creates a new file. If a file was Created, Deleted, and then Created, two PendingSyncItems will be created. The first one will be overlooked as the Deleted prop is true.

---