Easy System Level Undo
From Zanecorpwiki
Have you ever deleted a file by accident? Or later found out you really did need the information? "Undelete" is a feature we all need at some point. Yet, it's not always easy to come by.
Yet even advanced operating systems like Linux and Mac lack this seemingly simple feature. Most modern graphical OS or graphical OS overlays have the concept of a "Trash" where instead of just deleting a file, you put it in the trash. Now you must empty the trash before the file is really deleted from the file system. Until that point, you can restore the file.
These solutions are rarely technically perfect and they do nothing for shell based interactions, but they do solve a lot of the problem, and they do so very cheaply. So they're a great first step and very efficient, but it is possible to do much better.
Contents |
Phase 1: Immediate Undelete Support
WARNING: I haven't tested any of this yet. I will, but at the moment I'm just jotting down ideas. DO NOT take these scripts and just start using them. They will certainly have bugs and MAY CAUSE IRREPARABLE DAMAGE. I apologize if I'm getting your hopes up, but if you check back in a couple weeks, I'll try and get all this tested and production ready, but I'm crushingly busy at the moment, so it'll take a little while. I need to jot all this down though so I don't forget.
TODO: package and put together in install script. Drop manual install instructions and just scripts and just explain.
On *nix systems, you can roll your own undelete quite easily. First, copy this scripts below to their indicated locations. Make the 'rm_with_undelete' and 'check_and_clear_trash' scripts executable with "chmod a+x" and the script name/path.
Now add aliases with the 'ln' command for each of the scripts in $HOME/bin. If $HOME/bin is not in your path, then add it[notes 1]
TODO: explain how to configure and enable cron. Enabling cron will be automatic. Configuration steps should be captured in 'configure_rm_with_undelete' script that's run on initial install.
Scripts
config
Copy to $RMU_HOME
RMU_HOME="$HOME/.rm_with_undlete" RMU_TRASH="$RMU_HOME/trash RMU_BIN="$RMU_BIN" # You could 'computer' style GB, but not really necessary. I say # the computer doesn't care, so make it easy on the human. RMU_TRASH_SIZE=1000000000 # 1GB # To disable/enable periodic checks, comment/uncomment the next # line. # TODO: I think there's a shorthand for 'every 3 hours' # RMU_CRON_LINE="0 3,6,9,12,15,18,21 * * * $RM_WITH_UNDELETE_HOME/bin/clear_space # To disable/enable delete-on-delete mode, comment/uncomment the # next line. RMU_DELETE_ON_DELETE="true" # any non-z is true
rm_with_undelete
Copy to $RMU_HOME/bin
# rm_with_undelete
# TODO: add help and notes
CONFIG=$HOME/.rm_with_undelete/config
source $CONFIG
if [ ! - d "$RMU_TRASH" ]; then
mkdir -p "$RMU_TRASH"
fi
if [ ! - d "$RMU_TRASH" ]; then
echo <<EOF 1>&2
Cannot execute 'rm_with_undelete'.
No trash folder ("$RMU_TRASH") found.
EOF
# I believe if the user supplies '--force' then that overrides -i?
# TODO: check; Either way works for us though
rm -i $@
exit 1
fi
# all errors should have been checked and exit forced; otherwise,
# everything's good to go. Note, there's always enough space
# because on modern OS, a move is always just a reference change
# and never requires extra bits.
# TODO: need to audit differences in options
mv --target-directory "$TRASH" $@
if [ ! -z "$RMU_DELTE_ON_DELETE ];
"$RMU_BIN/check_and_clear_trash"
fi
check_and_clear_trash
Copy to $RMU_HOME/bin
TODO: THIS IS JUST PSEUDO CODE
USED=`du -s` # TODO: can we use DF for efficiency? perhaps alternate mode? # TODO: even better, in DU mode, cache last read and then update serially as files added/deleted. Now it's O(1). Add script to rebase number. Schedule periodic rebase? while [ $USED -gt $RMU_TRASH_SIZE ]; do # TODO: find and delete oldest file; 'ls' has some option, grab first line should work done
Phase 2: OS Level
Just a sketch, need to get back to work...
- Like (or use?) LV snapshots. Probably need to extend to associate changes with files, and then changes are tracked on as atomic changes to files. It's not a content diff, but bit diffs. Seems we should be able to recognize groups of changes so the file is always in a good state? Possibly not true for DB, but may be able to tell when true and when not? Maybe not. If not, then those files (hopefully not all though) are relegated to "delete only". If worst comes to worst, that's the default, but you can externally config which files can be tracked using tho OS level file manipulation stuff (and perhaps provide info on how to track so that more types can be tracked?). The config then influences the change log and undo-aware apps can make use of it by checking/querying for the files they're interested in and reacting appropriately.
- Now we just make a rolling, size-limited systemwide change log.
Can be accessed directly by user to undelete or roll file(s) back to a snapshot in time. Apps can also use for internal undos, or cross cutting "change management." Hook this into external storage, and you have an "always on" time machine.
Could configure for periodic and continuous remote and multi-location back ups.
For hardware level, use an SSD for the undelete and you may not even see performance degradation (unless you're already on all SSD system).
Notes
- ↑ Look for or add "
export PATH=$PATH:$HOME/bin" on most systems.
