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?
|
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 |
||||
|
|
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. |
|||||||||
|
|
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 It's also possible to add an alias for it to a startup script (e.g.
Edit: by the suggestions below, I've removed my advice to alias the default commands. Instead, it introduces new commands now). |
|||||||||||||||
|
|
One thing that I like to add to my .bashrc is a copy and remove function. Something like:
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. |
|||||||
|
|
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. |
|||||||||||||
|