/bin/grep
unless running it through "sudo" changes things...
/bin/grep
unless running it through "sudo" changes things...
Having found some likely block offsets using "grep -b", use the "dd" command to transfer that part of the disk to another file on another disk, where you should be able to inspect it.
If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
If at first you don't succeed, try writing your phone number on the exam paper.
that's the one trouble I'm having though, getting the offset...That's the exact command I'm using... am I doing anything wrong there?Code:sudo grep -b "GetDlgItem(hwnd, IDC_GRIPPIE)" /dev/sda2
Trick grep into thinking the drive is ASCII by passing the -a option. This way it will actually behave as expected.Originally Posted by @nthony
If you're booted from Ubuntu, then your grep is a "real grep."
Okay that seems to have triggered something, though I'm not sure what. A large amount of text is dumped into the terminal window and some lines of this text are prefixed with a number and colon:is that the byte offset?
Excitingly, some of the text I recognize as belonging to the lost file, however many of the lines are garbled and some lines that follow each other did not in the actual file. What does this mean... is this resultant from forcing some binary to display as ASCII, or is my file not stored contiguously (in which case, how would I ever locate the other parts?), or is it just mangled beyond rescue?
Also, what would be my next step to retreive it, from the man on dd, I've worked out I'll need to do something like: "dd if=/dev/sda2" count=(my file size, ~500kb) ibs=1 skip=(byte offset of file??)"
Yes, that big number is your "byte offset".
Garbled order may indicate that you are seeing blocks in "backwards order", e.g. blocks later on in the filesystem are lines of previous sections of file - which is fine. But it could also be other data/files that just happen to contain your file...
you probably want dd to look something like this:
--Code:dd if=/dev/sda2 skip={byteoffset} bs=4K count={some small number} >> somefile-not-on-sda2
Mats
You'll probably want to round down the block offset to some multiple of say 512. It depends how far you remember your search pattern was from the beginning of the file.
If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
If at first you don't succeed, try writing your phone number on the exam paper.
Does 1 byte = 1 block?
My file was ~250kb, so if I start 250kb before the offset and read 500kb, that should cover it to be safe right?
A disk-block is (in almost all cases) 512byte. I wouldn't necessarily expect the file to be in consecutive blocks - it could be, but it may also not be.
--
Mats
Meaning that I'd have to hunt down every block where parts of the file were stored in? (that would make it near impossible to salvage the entire file...)
p.s. mkdosfs combined with prolonged exposure to 60Hz refresh rate is giiving me a severe headache:is what I'm using to format my floppy disk, but mkdosfs simply returns "unable to open /media/disk"...Code:sudo mkdosfs /media/disk
Last edited by @nthony; 08-31-2007 at 08:33 AM.
Just save a HUGE chunk (e.g. a few MB) around where your file appears to be, load it up in some suitable editor and remove and re-order the text until it resembles the original. It is likely that large portions are in consecutive sectors, but you'd be quite lucky to have ALL in one consecutive chunk.
Did you also try /dev/fd0 or some such? [That probably won't work if it's a USB floppy]
p.s. mkdosfs combined with prolonged exposure to 60Hz refresh rate if giiving me a severe headache:is what I'm using to format my floppy disk, but mkdosfs simply returns "unable to open /media/disk"...Code:mkdosfs /media/disk
--
Mats
Unless your file system was nearly full, or horribly fragmented to begin with, chances are that most of the file will exist in a small number (hopefully just the one) of consecutive blocks.
The other problem being that if you used the disk since the file was lost, that some parts of the file may already have been lost for good.
If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
If at first you don't succeed, try writing your phone number on the exam paper.
Yea, put me down for the latter. At the time I was in such shock I completely forgot about trying to recover it and continued to use the computer for about a day afterwards...
I'll try what mat said incase the file was scattered across blocks, but I guess I won't be using a floppy for that then. I have a 64 MB USB key, but something tells me using it with Ubuntu is going to prove tricky, anybody know how I would go about doing this?
Recent versions of Linux handles USB keys quite well - I was surprised when I tried it lately and I didn't heve to do anything other than figure out what device it was.
Alternatively, use emacs to edit the file - there should be an emacs on the ubuntu.
--
Mats
You're right, I didn't think Ubuntu had PnP detection for USB keys, but as soon as I plugged it in, it brought up "/media/USB MEMORY"
I'm transfering data to it now, but dd is taking quite a while. Here's the command I'm using:I have quite a lot of work to do stilll as I noticed offsets occur at 65, 66, 69, 75, 92, 118, and 119 GB. I'll have to investigate each range in small increments... this could take me a very long time.Code:sudo dd if=/dev/sda2 skip=119648000000 bs=4000 count=2000 >> /media/"USB MEMORY"/part1
