Restore file from undo
Vsevolod Velichko
Please, help me with the following:
I've accidentally lost the folder with source code I wrote, but I have
vim undo-file for each file I've lost.
However, when I try to create new file with the same name as it had
before deletion, vim tells me that there's no undo/redo history.
Is there any way to replay the history from undo-file to recreate all
the files I had?
Thanks in advance.
----
Best wishes and have a nice day,
Vsevolod Velichko
Christian Brabandt
> Hello all!
>
> Please, help me with the following:
> I've accidentally lost the folder with source code I wrote, but I have
> vim undo-file for each file I've lost.
> However, when I try to create new file with the same name as it had
> before deletion, vim tells me that there's no undo/redo history.
>
> Is there any way to replay the history from undo-file to recreate all
> the files I had?
>
> Thanks in advance.
You can't. When reading the undo history, vim checks, that
the checksum between the undo-file and the current open file match and
that their line numbers are the same, if not, Vim will complain with
an error (if you have set verbose to a value larger than zero).
Even if you'd patch vim, to not check the hash size and number of lines
it wouldn't work, because the undo file does not contain the whole file
content, but only the content that changed between each file change.
So if you changed the source of vim, you could only recover the lines
that you actually changed, but all the lines that were not changed (and
therefore not recorded in the undofile) would still be lost.
That would only work, if you had previously reloaded your whole buffer
using :e! and 'undoreload' was set to a negative number (or you file
contained less than that number of lines). If you know, the whole
file content was previously saved in your undofile and you'd like to
try out reloading your changes, let me know. I made a patch, that
enables you to force reloading the undo history, which you could try out
if you want. But that is not very useful by itself.
regards,
Christian
Vsevolod Velichko
Christian, thanks for your answer.
Yes, all the files I've lost were created from scratch, so I suppose,
that undofile contains all the file history (undolevels=1000 should be
sufficient for every file).
----
Best wishes and have a nice day,
Vsevolod Velichko
2011/5/31 Christian Brabandt <cbl...@256bit.org>:
Christian Brabandt
> Christian, thanks for your answer.
> Yes, all the files I've lost were created from scratch, so I suppose,
> that undofile contains all the file history (undolevels=1000 should be
> sufficient for every file).
Ok then here is a patch. It allows to use :rundo! to let vim read in any
undo file. You need to create a new empty file with more lines, than your
original file had, e.g. 1000 empty lines. Then do :rundo! original_file.un~
and you can move through the undo history using g- and g+ or using
the :earlier :later commands.
The histwin or gundo plugin may also come useful to see your different
undo branches.
regards,
Christian
Vsevolod Velichko
less than 1000 undolevels in each file, but files more than one :)
The idea of grepping fs was the first one, but all the day (before I
found that the code has been deleted) I had filled my hdd with the
enormous dumps, so that there is no chance, that code is still placed
somewhere in the free space.
And, yes, the code was placed in the VCS working dir, just not
commited&pushed yet.
Christian,
thanks for your patch.
Unfortunately, it wasn't fully helpful, but I've recovered a lot of data.
Thanks for your help!
----
Best wishes and have a nice day,
Vsevolod Velichko
2011/5/31 ZyX <zyx...@gmail.com>:
> If files are so small that undolevels=1000 is sufficient, maybe you should
> retype them instead?
ZyX
sent 15:50:06 31 May 2011, Tuesday
by Vsevolod Velichko:
> Christian, thanks for your answer.
> Yes, all the files I've lost were created from scratch, so I suppose,
> that undofile contains all the file history (undolevels=1000 should be
> sufficient for every file).
If files are so small that undolevels=1000 is sufficient, maybe you should
retype them instead?
There are additional options: for ext* filesystems you may use extundelete
application and for every filesystem you may open its device as a file and
search for parts of the text you still remember. Before doing the latter, ask
somebody for application that is able to do the job, Vim is not a good option
for this. I once did something similar with grep.
And I guess you now know why people use backups. Mercurial+bitbucket.org or
something similar for your code can also serve for this need.
Original message:
Christian Brabandt
On Di, 31 Mai 2011, Vsevolod Velichko wrote:
> less than 1000 undolevels in each file, but files more than one :)
even if less then 1000 undolevels, it might still be valuable...
> The idea of grepping fs was the first one, but all the day (before I
> found that the code has been deleted) I had filled my hdd with the
> enormous dumps, so that there is no chance, that code is still placed
> somewhere in the free space.
> And, yes, the code was placed in the VCS working dir, just not
> commited&pushed yet.
>
> Christian,
> thanks for your patch.
> Unfortunately, it wasn't fully helpful, but I've recovered a lot of data.
I thought so. But even if it helped only a little bit, it's better than
nothing.
regards,
Christian
Christian Brabandt
On Di, 31 Mai 2011, ZyX wrote:
> There are additional options: for ext* filesystems you may use
> extundelete application and for every filesystem you may open its
> device as a file and search for parts of the text you still remember.
> Before doing the latter, ask somebody for application that is able to
> do the job, Vim is not a good option for this. I once did something
> similar with grep.
Hm, if I remember correctly, the inodes are zeroed out, when a file is
deleted for ext3 and ext4. That's why extundelete only works correctly
with ext2.
regards,
Christian
Vsevolod Velichko
> Hm, if I remember correctly, the inodes are zeroed out, when a file is
> deleted for ext3 and ext4. That's why extundelete only works correctly
> with ext2.
Not exactly.
There is even utility ext3grep[1] written by Carlo Wood, which
performs all the lookup for you. It can help in some cases.
[1] http://code.google.com/p/ext3grep/
ZyX
by Christian Brabandt:
> Hm, if I remember correctly, the inodes are zeroed out, when a file is
> deleted for ext3 and ext4. That's why extundelete only works correctly
> with ext2.
According to description of sys-fs/extundelete package it works only for ext3
and ext4, not for ext2 filesystem. I don't know anything about zeroing inodes
and I use neither extundelete nor ext* filesystems.
Original message:
Bram Moolenaar
Christian Brabandt wrote:
This is an interesting idea. Not only when the file was deleted, but
also when it was changed by another program.
Perhaps we can have a "starting point" marker in the undo file, where
the base file is completely empty. From there it's always possible to
repeat changes. With some command to do this, perhaps ":undorecover"?
When trying to load the undo file and the hash doesn't match, and there
is a starting point marker, we could give the user a hint that
:undorecover can be used.
--
I'm writing a book. I've got the page numbers done.
/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
Christian Brabandt
> 2011/5/31 Christian Brabandt <cbl...@256bit.org>:
>> Hm, if I remember correctly, the inodes are zeroed out, when a file is
>> deleted for ext3 and ext4. That's why extundelete only works correctly
>> with ext2.
>
> Not exactly.
>
> There is even utility ext3grep[1] written by Carlo Wood, which
> performs all the lookup for you. It can help in some cases.
>
> [1] http://code.google.com/p/ext3grep/
Thanks. I was refering to that part from the ext3 faq��:
,----
| Q: How can I recover (undelete) deleted files from my ext3
| partition?
|
| Actually, you can't! This is what one of the developers, Andreas
| Dilger, said about it: In order to ensure that ext3 can safely
| resume an unlink after a crash, it actually zeros out the block
| pointers in the inode, whereas ext2 just marks these blocks as
| unused in the block bitmaps and marks the inode as "deleted" and
| leaves the block pointers alone.
|
| Your only hope is to "grep" for parts of your files that have been
| deleted and hope for the best.
`----
It seems, this is not entirely correct, as stated in the ext3 undelete
HOWTO��.
extundelete��, ext3grep�� and ext3undel⁵ and might be helpful in
these cases.
That being said, I have no experience with any of these tools and just
wanted to add this info to this thread, just in case this might be useful
to anybody who stumbles over this thread via google.
Links:
��)http://batleth.sapienti-sat.org/projects/FAQs/ext3-faq.html
��)http://carlo17.home.xs4all.nl/howto/undelete_ext3.html
��)http://extundelete.sourceforge.net/
��)http://code.google.com/p/ext3grep/
⁵)http://projects.izzysoft.de/trac/ext3undel
regards,
Christian