mjhjmtu

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?

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

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, "CX256330x01pP326101~,252"3112022126021y377_S2542352262v3t"..., 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.

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.