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.
cp
was 1282 bytes and the size after usingcp
is now 3247 bytes. – Melab May 28 '15 at 20:44