Forgot to notrunc with dd--any recovery possible?
 

I was all set to test my bit twiddling of the allocation information in a big DB file--I'd dd'd out the portion of the file of interest and modified it. But I put it back--without using the conv=notrunc. Dang.

So, now this DB file, that should be 16GB long, is, uh, rather shorter. Is there any way to extend the length of the file again so that it will subsume the original contents? I know what the prior size was precisely and nothing's been written on the disk since the messed up dd truncated it, so I was hoping I could just tell the OS that it really is the original length and it might actually work. (I don't know how the space allocation works in Linux, so this might be a silly notion. But I figured I'd ask....) It should have truncated on a nice 2K boundary so I'm hoping there's nothing to indicate EOF in the data itself....

Any suggestions are most welcome!

Thanks,

John

(This was a test setup so it's not critical that I recover this in place, but I'd like to know if it's possible.)

It should be possible in the manul mode (read: using hexedit or similar tool with filesystem reference). Ordinary tools... Much depends on the filesystem you have. Which one is it?

That might work if the entire file was on consecutive blocks. It might be, it might not be. If it was, you could try

dd if=/dev/zero bs=1 count=0 of=<file> seek=<filesize>

which would write 0 bytes to the file (!), but as a side effect it would seek to the end of the file first, thus setting the filesize. WARNING: This is just off the top of my head, I have no idea whether this could even theoretically work. So don't even think about it unless you backup the entire partition first.

For a more sensible approach, it depends on your fs. If it's ext2/ext3, you could try debugfs (I used this once to recover some files without knowing wtf I was doing, but I winged it! rtfm! ;)). There is a debugreiserfs command but I don't know if it has the capability to recover files. Again, backup the partition first, if you have the space.

File system type
 

The fs is ext2 and I'm guessing that the file is on consecutive blocks because of the way it was created (two big DB files put on one after the other--first things on there other than the fs goo). I'll check out the suggested tools! Thanks. (BTW, I love the dd option--very clever.)

I won't be backing it up since what I have is a backup of the DB and I can eliminate the file and rebuild it and then reload the DB.

John

Didn't manage to extend file
 

Well, just BTW, I didn't manage to extend the file. I tried the dd trick of writing nothing but giving the original file length. For whatever reason, it didn't work. I didn't spend much time fussing with trying to figure out why since the recovery was straightforward.

Thanks!

John