Make actions reversible

[simonsan]

It would be beneficial that users could be reverting the changes organize has done. For this we could either utilize an embedded database (e.g. sled) or just have json files in a configuration directory.

Possible schema

Reverting an action on the filesystem made by your app requires tracking changes in a structured manner. This way, you can easily reconstruct the prior state. A schema to track these changes would need to contain a minimum set of attributes to describe both the initial and final state of every action.

Here's a suggested schema:

1. Actions Table (Unchanged)

• ActionID: Unique identifier for the action.
• Timestamp: When the action was performed.
• ActionType: Type of action performed (e.g., Move, Rename, Delete, Create, FolderMerge).
• UserID: Identifier for the user who performed the action.
• ApplicationVersion: The version of the app at the time of the action.

2. Entities Table

• EntityID: Unique identifier for the file or directory.
• ActionID: Foreign key linking to the Actions Table.
• EntityType: Designates if it's a file or directory.
• OriginalPath: The full path of the file/directory before the action.
• FinalPath: The full path of the file/directory after the action.
• OriginalName: The name of the file/directory before the action.
• FinalName: The name of the file/directory after the action.
• HashBefore: A hash of the file content before the action (only relevant for files, can be null for directories).
• HashAfter: A hash of the file content after the action (same as above).
• SizeBefore: Size of the file or total size of the directory before the action.
• SizeAfter: Size of the file or total size of the directory after the action.

3. Metadata Table (Unchanged)

• MetadataID: Unique identifier for the metadata entry.
• EntityID: Foreign key linking to the Entities Table (was previously FileID).
• MetadataType: Type of metadata (e.g., tag, date, author).
• OriginalValue: Value of the metadata before the action.
• FinalValue: Value of the metadata after the action.

How Reversion Works Using This Schema:

1. The user selects an action to revert (either through a UI element like a history log or some other mechanism).
2. The app identifies the ActionID to be reverted.
3. All associated file changes (from the Files Table) with that ActionID are fetched.
4. For each file change:
   • If the action was a Move, the file/folder is moved from FinalPath back to OriginalPath.
   • If the action was a Rename, the name is reverted from FinalName to OriginalName.
   • If the action was a Delete, the app will need a way to recover the file (either from a recycle bin, backup, etc.) and place it back at the OriginalPath.
   • If the action was a Create, the file at FinalPath is deleted.
5. Metadata changes, if any, are also reverted.
6. A new action log is created, describing the reversion action.

When reverting directories:

• For Move or Rename, the whole directory and its contents are moved or renamed back to their original state.
• For Delete, the directory and all its content need to be restored. This is complex and might involve more advanced mechanisms like snapshots or backups.
• For Create, the directory and its contents are deleted.
• A new action type, FolderMerge, might be considered. This is when two folders are merged. To revert, you'd need to ensure that the contents of the folders are separated back to their original folders.

Edge cases

For example, if we're trying to revert the deletion of a directory, but a file or folder with the same name now exists at the original location.