# Do we have an undo in Linux?

I renamed a few files in one batch script. Is there a way to undo the changes without having to rename them back?

Does Linux provide some native way of undoing?

-
We do have "don't do" there. Do you? –  poige Aug 19 '11 at 3:13
wow, a computer gag! ajhaha –  erm3nda Dec 9 '13 at 20:23
–  kenorb Oct 24 at 21:34

Linux (like other unices) doesn't natively provide an undo feature. The philosophy is that if it's gone, it's gone. If it was important, it should have been backed up.

There is a fuse filesystem that automatically keeps copies of old versions: copyfs, available in all good distributions. Of course, that can use a lot of resources.

The best way to protect against such accidents is to use a version control system (cvs, bazaar, darcs, git, mercurial, subversion, ...). It takes a little time to learn, but it pays off awesomely in the medium and long term.

-

Unfortunately, no.

-
I don't know that I consider this unfortunate... It would take quite a few resources to implement an undo. I don't even like the -i option on rm enabled by default. My Unix systems should not hold my hand. –  xenoterracide Aug 22 '10 at 8:18
-i is enabled by default?! not my distro, no sir! –  Stefan Sep 5 '10 at 19:36

There is no undo in the command line. You can however, run commands as rm -i and mv -i. This will prompt you with an "are you sure?" question before they execute the command.

It's also possible to add an alias for it to a startup script (e.g. ~/.bashrc or /etc/bash.bashrc):

alias remove='rm -i'
alias move='mv -i'


Edit: by the suggestions below, I've removed my advice to alias the default commands. Instead, it introduces new commands now).

-
+1. just to add here. After setting above aliases if in some cases you want to just directly remove without "are you sure" prompt you can use \rm and \mv to bypass alias. you can also use -f option. –  Hemant Aug 22 '10 at 9:12
mv -i prompts only when it would overwrite a file (which makes it useful and not obnoxious). In the same vein, alias cp='cp -i'. –  Gilles Aug 22 '10 at 9:54
Aliasing rm and mv is a very bad idea. (rm is worse of all.) Never get in the habit of using rm to mean rm -i -- you'd eventually use it somewhere where the alias is not defined and you'll delete something for good. If you like being prompted, get in the habit of using rm -i all the time. –  msakr Aug 22 '10 at 13:35
If you like being prompted, use an alias under a different name. I use move='mv -i', copy='cp -i', symlink='ln -si', and install a trash command to use instead of rm. I still use mv, cp, and rm directly when scripting, but for interactive use these aliases are handy. –  Roger Pate Aug 23 '10 at 5:49
@mahmoudsakr You're completely right, I missed that point. I don't have these commands aliased either. Aliasing them as a different command seems like the most sane option! –  vdboor Aug 23 '10 at 7:29

No there is no magical undo in any Unix. Unix assumes that you know what you are doing. For Undo support use a VCS (your text editor probably has it built in too).

Most filesystems do not have the capability of doing it transparently.

Time machine and system restore on mac and windows respectively are just backup/change control systems.

-

One thing that I like to add to my .bashrc is a copy and remove function. Something like:

cprm(){
cp -p $1 ~/deleted/$1
rm $1 }  But you do have to get into the habit of typing cprm not rm. Obviously you will need to keep on top of the deleted area if you have limited diskspace. - you could really shorten that to mv$1 ~/deleted/$1 – Stefan Sep 5 '10 at 19:37 yes, and it will overwrite a file 'new Document 1' with another one 'new Document 1', if you get the quoting right: "$1". –  user unknown Aug 18 '11 at 6:11

The reason that Linux/Unix systems don't have an undelete stems from the way most filesystems store their information. File meta-information is all stored in the front of the disk with references to inodes on the rest of the disk. Typically, most filesystems allocate 10 blocks to a file in this meta-area. The first 7 refer to the first 7 inodes. The 8th and 9th go to lists of inodes (doubly linked blocks) and the 10th goes to a list of lists of lists (tripply linked blocks). This varies from file system to file system (ext4, jfs, xfs, etc.) but these lists of blocks can usually address file sizes of anywhere from 2GB to several TB.

But because all this information is stored in the front of the disk, when a file is erased, there is no way to reference inodes on disk to what meta-data they use to belong to. In contrast FAT32 and NTFS actually store some header information with the files themselves making it easier to identify what file a set of blocks use to belong to (so long as that space hasn't been reclaimed by newer files yet). In the Linux work, when you delete something, it's almost always the first thing to be immediately overwritten by new data for efficiency.

-

If you really want an undo feature, use source control. Subversion actually works very well on a single user machine. I use it to control all my personal files on my home system. It seems like overkill, until disaster, a rogue script or a command line typo hits.

-
It won't protect you from rm -r . though. ;) –  Umang Aug 22 '10 at 10:11
@Umang I actually did that once with git, where I keep a local repository and accidentally rm -r project.git. Fortunately if you keep another version on a remote server that's unlikely to happen –  phunehehe Aug 22 '10 at 13:37
@phunehehe and whoever +1'd my comment: we're too used to DVCS to realize that I was completely wrong. SVN commits to the repo (which isn't the branch). So you will actually be protected rm -r .. Really stupid of me. –  Umang Aug 22 '10 at 16:43