Do we have an undo in Linux?

Question

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?

Answer 1

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.

Answer 2

Unfortunately, no.

Answer 3

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.

Answer 4

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).

Answer 5

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.

Answer 6

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.

Answer 7

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.

Answer 8

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

Docs: https://www.presslabs.com/gitfs/docs/usage/

Answer 9

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).