3

I accidentally misused the cp command and overwrote one file's contents on an ext4 filesystem. Is there anyway I can recover this old file's contents and possibly its metadata (i.e., last write time, etc.)?

I'm aware that mv frees up blocks for moves, but does the same apply for a wholesale copy operation?

Melab
  • 4,048
  • It depends on the type of filesystem. But unfortunately the spectrum of answers for different types of filesystem is likely to range between almost impossible and theoretically doable yet quite difficult. – Celada May 28 '15 at 17:52
  • exact command you used? file size before / after? – frostschutz May 28 '15 at 19:14
  • @Celada It is ext4. – Melab May 28 '15 at 20:38
  • @frostschutz The size before using cp was 1282 bytes and the size after using cp is now 3247 bytes. – Melab May 28 '15 at 20:44
  • 2
    @Melab Before doing anything, did you switch off any write operations on your partition/hard-drive? Just do it. The first thing to do in such cases is always to switch off the hard-drive/partition. When you have a solution, use it to extract your data. Until then DO NOT USE THAT HARD-DRIVE. – shivams May 28 '15 at 21:23
  • Which file type ? Know any contents I n it ? – totti May 29 '15 at 10:58
  • Depends how valuable the data is, as it is not easy. For now stop using the hard-disk, every operation on the disk will reduce your chance of recovery. For the future, learn and use a revision control system, and backup the repositories to a remote location. – ctrl-alt-delor Feb 10 '19 at 15:21
  • You appear to have gone away, edit your question and answer the questions in the comments, then your question will be reviewed. – X Tian Feb 10 '19 at 18:43
  • As i know is very difficult to recover a deleted file but try this in 2005 i use this tool on ext3 partition and recover a lot of files. Of course make a backup before use this and remind is not 100% guarantee to recover files – elbarna May 28 '15 at 18:03
  • @elbarna I converted your answer to a comment since it wasn't actually an answer. Please feel free to post again if you can add some details, the specific command, how to install it and how to use it to do what the OP is asking for. – terdon Aug 04 '22 at 15:50
  • 1

3 Answers3

2

Example session in an ext4 filesystem:

Create two files a, b with your specified size:

# dd if=/dev/urandom of=a bs=1282 count=1
1+0 records in
1+0 records out
1282 bytes (1.3 kB) copied, 0.000647314 s, 2.0 MB/s
# dd if=/dev/urandom of=b bs=3247 count=1
1+0 records in
1+0 records out
3247 bytes (3.2 kB) copied, 0.00106112 s, 3.1 MB/s

Check where a is allocated physically:

# filefrag -sve a
Filesystem type is: ef53
File size of a is 1282 (1 block of 4096 bytes)
 ext:     logical_offset:        physical_offset: length:   expected: flags:
   0:        0..       0:      32833..     32833:      1:             last,eof
a: 1 extent found

Copy b to a, thereby "overwriting" a. (Output shortened.)

# strace cp b a
open("a", O_WRONLY|O_TRUNC)             = 4
write(4, "CX\256\330x01pP\326\0101~,\252\"\311\202\21\260\21y\377_S\254\2\352\262\v\3\t"..., 3247) = 3247

Check where a is located physically after cp:

# filefrag -sve a
Filesystem type is: ef53
File size of a is 3247 (1 block of 4096 bytes)
 ext:     logical_offset:        physical_offset: length:   expected: flags:
   0:        0..       0:      33280..     33280:      1:             last,eof
a: 1 extent found

Note the location changed from 32833 to 33280. Which means the original data is probably still to be found at 32833 - in this example.

What happened is that cp truncates the output file so for a moment, it's a 0 byte file. That's nearly the same as deleting it, except it re-uses the inode. Writing to that file allocates from anywhere in the free space, which may be somewhere else as the old file used to be.

So there might be a chance of recovery if you know some part of the file content so you can locate it in the raw data. This is what photorec does but only for known file types with distinct headers. extundelete probably won't help as the file's inode wasn't really deleted, rather just re-used for the new file.

frostschutz
  • 48,978
2

Depends how valuable the data is, as it is not easy. For now stop using the hard-disk, every operation on the disk will reduce your chance of recovery. For the future, learn and use a revision control system, and backup the repositories to a remote location.

If the files is removed, but is still open by some process, then it will not be deleted. It can still be recovered, by finding a reference to it, in /proc, and copying to a new location.

0

https://github.com/PabloLec/RecoverPy This tool solved by issue I accidentally saved the file empty... When I reopen file it was empty.

This tool can scan blocks in your drive using a keyword. This tool is specially made to recover overwritten files content not your typical deleted file. But content that is still saved on blocks in your drive.

How to use:

  1. Select the drive you plan to perform the search you need to move the arrow keys then click enter to select the drive
  2. perform a search for keyword you know for certain the file contains
  3. It will bring search results, click on one that contain keyword you looking for
  4. Then you can navigate to nearby blocks and select them to be added to a file
  5. Once you have all the blocks you plan to add to the file click on save file and it save a file in your tmp folder.

This tool is amazing since I manage to recover a file with nearly 4000 lines... It was my notes for some research I have been doing. (Yes I should had made a backup) and I learned my lesson and now the file is online.

John
  • 11
  • I realize that it’s impossible (or, at best, highly impractical) to post a tool in an answer, but can you please [edit] your answer to give some explanation of how this tool works (what are its capabilities and limitations?) and how to use it? – G-Man Says 'Reinstate Monica' Aug 02 '22 at 16:21