Hi,

By mistake I had overwrite a file that was filled with important logs
Is there any quick way to recover it?

Following steps taken:
root@# cp xyz_log.today xyz_log.today_2
root@# cp /dev/null xyz_log.today

However xyz_log.today_2 already exists

Any help?
Thanks in advance.

midnight commander can recover deleted files, but if it was overwritten I think you are out of luck

Hi,

If you do not have a backup of the overwritten file you are out of luck....

Remember: Linux and Unix have the "You know what you are doing" philosophy. No "Are you sure" and "Are you really sure" questions by default (opposed to Windows).

If you are worried about this, make an alias for the cp and/or mv commands (in .profile or .bashrc) that includes the -i flag, something like: alias cp='cp -i'. The -i flags does the following: prompt before overwrite.

Hope this helps.

Travel back in time, create a backup like a good technology professional, and then restore from that backup.

0 members found this post helpful.

Wait!!

Let's think about what it means to "overwrite" a file. If I understand it correctly, the filesystem keeps track of filenames and the location(s) of the data on the disk. If, for example, the file is deleted, the actual data is not erased----the system simply releases the blocks and make them available for new data.

If you attempt to write a file with the same name as one existing, then you are prompted as to whether you really intend to do this. If you say yes, it is not obvious to me that the filesystem will use the same physical locations.

Some simple experiments should be able to confirm...

Hi,
That part is true.
The bold part is only true if the command/script has been told to do this (using -i with cp/mv or a piece of code that checks the existence of a file and acts accordingly for example).

A simple example:
The original lg.lcd.tv.pdf is overwritten but still has the same inode index and block group associated with it (= same physical location on disk).

This test is done on an ext3 FS.

If you are over-writing a file from the GUI, then you would typically be prompted by default.

My theory is mostly based on over-writing a file with one that is longer, but I have not been able to test it yet.

Hi,

Which is in the line of my previous reply: The gui (I assume you mean some sort of file manager) is programmed to check this.

Also: I am taking the OP's original post as a starting point (command line, not gui).

I'm curious what your results will be, please post them if you have done them!

I created a small partition and filled it to about 80% with random files.

I then copied a small file to the partition, and noted the location using
Then:
1. edited the file to be ~10X larger. Repeated the hexdump and found the old file intact, and the new longer file at a new location

2. changed 1 word in the longer file--keeping the file size the same: The system saved this to another new location---and both of the two older files were still visible in the hexdump.

In all cases, the inode number remained the same.

conclusion: Do not assume that over-writing a file destroys the old file.

PS:
I have not done enough testing to know if the behavior is different when modifying and then copying the file vs simply modifying it in place. My intuition is that it should not matter.

@pixellany: Nice test, have to try that and have a better look with debugfs.

At first glance it looks like the (data) blocks that the original file used are not necessarily overwritten, but on an active (running) partition they probably will be in a relative short time due to the "defragmentation" mechanism:
In theory you can probably restore parts (most?/all??) of the overwritten file by immediately "freezing" the partition it happened on, look for and gather the still available blocks and put them back together (possibly filling in the missing gaps yourself). Having just one partition (probably true for most users) makes this a lot harder to do.

Guess the conclusion should be: Yes, (partial) recovery is theoretically possible, but very hard to do in real life.

BTW: I came accross this article: HOWTO recover deleted files on an ext3 file system. Interesting read.

Here is my experience.

I accidentaly copied over a text file using cp. This file I've been editing for
about 3 months now, about once per week.

I use reiserfs filesystem and have a separate partition for /home.

I realized the blunder immediately and took the following steps.

1. I became a root, changed to root's home and unmounted the partition:

$sudo su -
#cd
#umount /home

2. Find out which partition is mounted as /home. In my case it was /dev/sda2
so that's what I'm gonna use from this point on.

3. If it's a text file you've been editing yourself, you probably remember some
words that you used. These words you will use as a search pattern to look for
your file (the more specific the better). You also approximately remember the size
of the file - as a number of lines or smtng. Say, you know that the file was about
800lines long and you know for certain you've had the word "soldier" somewhere
in that file.

4. With this information, you will pattern-search your unmounted /home partition
using the following command:

#grep -a -A800 -B800 'soldier' /dev/sda2 | strings > recovered_file

This might take a while.

5. Look thru the file "recovered_file". It will probably be very large. If you've
edited your lost text file more then once, you will for sure find several
instances of the text file you're looking for. A different copy for every time you edited it. You probably want to recover the very last instance.

2 members found this post helpful.

Great @frankie_DJ I recovered my four hours overwritten files.