# 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?

• Oct 24, 2014 at 21:34
• For anyone coming here: check this recent post which have more recent/relevant answers Sep 10, 2020 at 7:06

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. Of course, that can use a lot of resources. Unfortunately, it's unmaintained. Gitfs might be an alternative, I've never tried it.

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.

• good alternative might be gitfs, which is under devlopment Feb 4, 2016 at 13:23
• Well if you accidentally delete or overwrite a file that you did not stage or commit yet then even a CVS does not help Nov 2, 2017 at 11:55
• Not correct since more than 10 years. ZFS..... at least it is possible to jump back in time if the system is setup such that things is snapshoted fairly recently (and often.) And ZFS is NATIVE in Solaris soo... Jul 19, 2021 at 17:04
• @StefanSkoglund That's very far from being an undo. You can jump back in time to a previous snapshot. You can't undo the deletion of a file that was created after the last snapshot, for example. Jul 19, 2021 at 18:58
• backup wont give you an undo neither. Though ZFS (and other system like) that has its warts including this: a lot of alike disks in usage ? One fails ? Ok ZFS will probably protect against that .... but alike disks ie made at about the same time at the same production line ? When will the next one fail ?? Jul 20, 2021 at 12:46

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. Aug 22, 2010 at 8:18
• -i is enabled by default?! not my distro, no sir! Sep 5, 2010 at 19:36
• I never seen such a short answer with so much upvote before :D (no offense intended, I'm just genuinely surprised) Sep 10, 2020 at 7:02

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.

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. Aug 22, 2010 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'. Aug 22, 2010 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. Aug 22, 2010 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, 2010 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! Aug 23, 2010 at 7:29

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. ;) Aug 22, 2010 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 Aug 22, 2010 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. Aug 22, 2010 at 16:43
• If you don't run under a root account, or in sudo, all the time, it should protect one against rm -r'ng the version control database/files.. Especially if your version control software of choice has the ability to run as a daemon under another user context, and is configured to store files under that other user's folders which don't have write permissions by any other account, but root. There is ways to prevent a decent portion of mistakes with thoughtful planning of system setup. Dec 31, 2020 at 15:53

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 Sep 5, 2010 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". Aug 18, 2011 at 6:11
• @userunknown: do you mean $1 in Deano's and Stefan's code should be quoted as "$1"?
– Tim
Mar 25, 2015 at 6:37
• @Tim: Yes, I do. Mar 25, 2015 at 15:25
• Why not do move instead of cp and rm? Nov 27, 2018 at 15:11

GitFS is a fuse-based file system, which automatically calculated diffs between versions and allows restoring/browsing across them.

Webpage: https://www.presslabs.com/gitfs

No, out of the box you don't have something as undo. That's not that different to most other operating systems: when you delete a file under windows it's just as much gone. However, graphical frontends (on most systems) tend to default to moving files to some trash directory. That way you can undo deletions - but it's not a feature of the operating or file system, it's just a GUI tool that has a functionality called "delete" that does not actually delete.

Now, Linux by now has multiple options to at least give you something that you would call a "save point" in a game; a place that you could always restore back to.

These are usually called "filesystem snapshots", and are exactly that. The zfs and btrfs file systems have built-in support for these! You just say: "it's Monday, the day I always make a snapshot", and the file system then keeps the version of your files at that point; any changes atop of that are stored separately, so that you can go back to your snapshot, mount it, say "hey, here's Monday's version of that file" and be happy.

This is different from a backup as the data really just stays there once - but it means that if you have a 1 MB file on Monday, take a snapshot, then completely overwrite it (intentionally) with a different megabyte of data on Tuesday, then that will need 2MB of storage. But it's still a very cheap operation, and very useful.

As said, some file systems can do this all by themselves; others need to be run atop of LVM/thin LVM, which allows you a less well-integrated method of taking snapshots (which then happen on "changed blocks", not on " changed file" basis and might be less space efficient).

• ZFS is native in Solaris and the open offshots of that (Illumos for example.) Snapshots can be done fairly recent and often because the operation as such is fairly cheap. Jul 19, 2021 at 17:10
• Well, the ZFS kernel modules for Linux seem to have reached a high level of sophistication by now. Yep, snapshots are cheap -literally just the cost of the changed data.
– mmmm
Jul 20, 2021 at 23:06