> The major obvious technical issue is simply running out of space, and how you deal with that informs many other aspects of such a system.
The same problem exist with any other kind of undo option. For example, your text editor's undo option might run out of memory. Yet, we have undo in text editors.
> But you don't directly make calls to the filesystem; deletions or updates are always issued by a process acting on your behalf.
Yes, so ideally, any system command (such as "mv") should write a small journal to some undo system, saying what actions are necessary to undo the command. When those actions are logically grouped, then the undo system's journal should reflect that.
Of course, it would be even better if the filesystem just worked with nestable transactions, like a database.
The same problem exist with any other kind of undo option. For example, your text editor's undo option might run out of memory. Yet, we have undo in text editors.
> But you don't directly make calls to the filesystem; deletions or updates are always issued by a process acting on your behalf.
Yes, so ideally, any system command (such as "mv") should write a small journal to some undo system, saying what actions are necessary to undo the command. When those actions are logically grouped, then the undo system's journal should reflect that.
Of course, it would be even better if the filesystem just worked with nestable transactions, like a database.