Provide system wide filesystem Undo with a transactional filesystem
I unzip a file. My home directory is filled with thousands of individual files. Undo.
I accidentally swap the arguments to a command and overwrite my data. Undo.
This blueprint proposes replacing or augmenting the default filesystem under ubuntu to allow the filesystem to revert arbitrary operations whenever possible. Overwritten files can be underwritten, deleted files undeleted and arbitrary move, copy and linking operations reversed. Given the ever increasing amounts of personal storage available, it is ludicrous that I can not recover a 10kB file that I actually care about. A likely implementation pathway is to add transactional operations as seen in data bases to ext3 (extending the existing journaling mechanism, and bringing the functionality right through to nautilus).
Blueprint information
- Status:
- Not started
- Approver:
- None
- Priority:
- Undefined
- Drafter:
- None
- Direction:
- Needs approval
- Assignee:
- None
- Definition:
- New
- Series goal:
- None
- Implementation:
-
Unknown
- Milestone target:
- None
- Started by
- Completed by
Related branches
Related bugs
Sprints
Whiteboard
I think newer filesystems like btrfs, ext4, and some others maybe the way to go with this.
--Joshua Blocher
http://
Some issues to consider:
* Undo what? There may be lots of things happening on the filesystem. If a package was being installed while you were unzipping that file, then you ideally don't want any of that package install to be undone (or at least you want to make sure that the package install is completely undone rather than leave things in an inconsistent state).
** In the case of unzipping in some deep subdirectory of one's home directory, it probably suffices to specify the base directory and a timestamp range, but maybe that wouldn't be enough if the directory in question was where one's web browser is downloading a file at the same time.
** Maybe Unix notions like session group and process group could help. Or even just the process hierarchy established by fork. This would be consistent with undoing the actions of a particular shell command.
* “Transactional” implies that the start & end of a transaction are marked so that all or none of the transaction is undone; but marking that start & end implies extra programming (at least if one wants to consider "install a package" as an atomic transaction rather than merely considering each syscall as a transaction).
* If you want to undo something from ten minutes ago, then what happens to the other stuff that's happened since?
* Whenever one is considering adding undo history to software, one should also consider whether it's worthwhile to go one step further and offer version control operations including merge operations, so that one can "cherry-pick": undo stuff from ten minutes ago without undoing changes since then that touch the same files or directories. For existing filesystems that allow merge operations, look at distributed filesystems and in particular filesystems that allow disconnected operation, such as coda or (possibly) intermezzo. (Though I think some filesystems offering disconnected operation do so by forbidding writes at all but one site.)
* What are examples of where we want to "undo reads" of writes we've undone (or rather undo actions that resulted from those reads) ? For Beagle, it suffices that it gets sent new notifications of the undo. That won't work for the ‘crontab’ command (which sends cron a signal after editing the file). ‘make’ will be confused, but maybe that's just evidence of timestamps generally being the wrong approach. It's too late to undo the result of adding a file to a mail or print spool.
