How to recover files truncated by `>`?

Question

I had a text file hello.txt which contains about 100 lines.I accidentally deleted all the lines by running echo > hello.txt

Now i want to recover all the 100 lines.Is there any way to recover the lines in that file using terminal commands?

This is what backups are for. If you have backup setup in Ubuntu, you can open Nautilus (Files icon in Launcher) and right click on the hello.txt file and revert it to a previous version. — user68186, Jan 09 '14 at 17:34

score 3 · Accepted Answer · answered Jan 09 '14 at 17:41

3

You can not get back the contents. There is no mercy.

But search for backup files. If you are lucky enough there will be a file named hello.txt~ for hello.txt in the same directory. Those files are usually created by text editors like gedit or emacs when you edit a file.

If you have such backup file you can get the contents back (you may get back only a part also). Use the following in the terminal,

mv hello.txt~ hello.txt

It is better to have even a part than losing it completely.

answered Jan 09 '14 at 17:41

sourav c.

44,715

i tried to find hello.txt~ file by running ls command on that directory.Now i can be able to see that,and then move the contents to hello.txt file.Now it works. – Avinash Raj Jan 09 '14 at 18:10
1

Note that backup files are specific to each utility. vim creates file.txt~ type of files, and also file.txt.swp type which contains undo-redo history ( see also ). nano text editor has .save files so automatic backups depend on the utility and whether or not utility has such feature. Best practice is to explicitly backup or copy files before redirection. – Sergiy Kolodyazhnyy Feb 28 '19 at 21:30

JamesThomasMoon · Answer 2 · 2019-02-28T19:56:11.113

tl;dr Skip to the end for the working solution.

I accidentally truncated a file using gedit. It was truncated from 1800 kB down to 25 kB.

I wanted to share a few recovery techniques I attempted. This isn't meant to be a definitive answer, more a collection of answers to try. This is similar to this post.

First, remount the filesystem as readonly!. Do this as soon as possible.

sudo mount -o remount,ro /

In my case, I was unable to remount readonly, so...

The mount command failed. with error mount: / is busy.

I recommend the drastic step of just hard powering off your machine. Yes, drastic! But I don't know how long the remnants of the truncated file will be around. They may be overwritten at any moment. Boot up into the Ubuntu LiveCD.

Per a comment here, I ran telinit 1 which dropped down to init level 1. This only complicated things so I don't recommend doing telinit 1. I recommend the hard power down.

attempt using ext3grep

Following this blog post and this email thread, try using ext3grep.
However, ext3grep failed for me. I was only able to recover the truncated file.

attempt using sleuthkit

sleuthkit is cool toolset. You'll probably have to install it. Again, this get's tricky if the truncated file was the / mount. Again, I recommend hard powering off and then running a LiveCD. Using this blog post, and this blog post, the instructions are essentially

apt-get install sleuthkit
stat truncated-file | grep Inode
remember the inode number (call it INODE_NUMBER)
backup the file, then delete it:
cp -a truncated-file truncated-file.old
rm truncated-file
1. debugfs /dev/disk-device
2. stats
  look for Blocks per group
  This is very likely 32768. (call it BLOCKS_PER_GROUP)
3. imap to get the block
  imap <$INODE_NUMBER>
  remember the block number (call it BLOCK_NUMBER)
use blkls to copy the blocks to a file
blkls /dev/disk-device $BLOCK_NUMBER-$(echo '$BLOCK_NUMBER+$BLOCKS_PER_GROUP-1' | bc) > recovered-file
manually review and clean up recovered-file using some editor program

But sleuthkit did not work for me. Only the truncated file was recovered.

attempt using extundelete

From this forum post.

attempt using grep

From this post, grep for some known string in the truncated file. This is the only method that worked for me.

grep -a -A 1000 -F 'some known string' \
    /dev/disk-device > recovered-file

Surprisingly simple, eh?

score -1 · Answer 3 · answered Jan 09 '14 at 17:30

-1

Sorry friend, It's impossible...

You can recover deleted files but you can't recover a file with deleted content..

answered Jan 09 '14 at 17:30

Maythux

84,289

2

I don't really know much about filesystems, but I imagine that when you just set a file to zero bytes, such as OP did, the disk doesn't really erases the content of the file. I believe it just sets the file to zero bytes so that the previously occupied space becomes "free". So it should be theoretically possible, if I'm right (of course, that assumes that the hard disk wasn't writed on since the operation)... what do you think? I'll do some googling. – GabrielF Jan 09 '14 at 17:36
When u make some file the OS will just reserve the space needed for the file. anyway this 1 and 0 is not really much true there is no really 1 and no really 0 there are values near to 1 and 0. Anyway. when some body write in afile the space is reserved. when u delete u make 1 will stay 1. I mean the Os will still showing that this file is found so it will write the new file just over the old one with the same offset and start and end sectors. So its impossible, anyway i hope you can find something else with google – Maythux Jan 09 '14 at 17:40
@Maythux it was possible! See my answer. :-) – JamesThomasMoon Feb 28 '19 at 19:54