Recover files from CF card

[Sim085]

Originally Posted by mark_k

When I wrote "DOS\0" I meant the ASCII letters DOS followed by a zero byte. In hex, those bytes are: 44 4F 53 00

Ok I understand now.

Originally Posted by mark_k

44 4F 53 00 00 00 00 00 00 00 00 00

I found a lot of instance when searching for the above. I attached a screenshot as I am not sure if all entries are relevant. I see CrossDOS, MS-DOS etc... (01.png).

Originally Posted by thomas

Most likely the partitions begin with DOS\1 a.k.a. 44 4F 53 01 (FFS) or DOS\3 a.k.a. 44 4F 53 03 (FFS INTL).

I also did a quick search for 44 4F 53 01 00 00 00 and I found five instance of this in the image file at the following lines:

0007e000
003f0400
le94cc00
5a373a00
6c3ec00

Now I just have a question and I promise this is one of the last ones before giving up; How do I determine Cyl (for LowCyl and HighCyl) from the line numbers? Or it is not something that strait forward?

[thomas]

A partition always starts on a block boundary, i.e. on an address which is divisible by 512 a.k.a. hex 200. Furthermore it should be obvious that "DOS" does not apply to the beginning of a partition if it is part of "MS-DOS" like in your first screenshot .

You have to search for DOS in the beginning of a line whose number ends in 00 and has an even number or letter a, c or e in the third last place. The second screenshot shows such a number for example.

Getting the cylinder numbers is more difficult. First you have to calculate the block number. You do this by dividing the line number by bytes per block. If you switch the Windows calculator into "Programmer" mode, you can enter hex numbers. Block size is dec 512 resp. hex 200. So you divide 7e000 by 200 resulting in 3f0. If you now switch to decimal you get the block number 1008. (Another way would be to enter 7e000 and then switch to dec which results in 516096. Then divide it by 512 to get 1008.)

In order to get the cylinder number from the block number, you have to divide the block number by the number of blocks per cylinder. Knowing that HDToolbox always starts the first partition at cylinder #2, I would guess that blocks per cylinder is 504 and thus 1008 / 504 = 2 is the lowcyl value for the first partition.

The highcyl value is usually one less than then the lowcyl value of the next partition. The highcyl value for the last partition is one less than the number of cylinders on the drive.

Note that all this is built into RDBRecov. Once it works correctly, it will tell you all the values you need.

[mark_k]

Originally Posted by Sim085

I found a lot of instance when searching for the above. I attached a screenshot as I am not sure if all entries are relevant. I see CrossDOS, MS-DOS etc... (01.png).

The only possibly-relevant entries are where the DOS string begins on a 512-byte boundary as Thomas said.

Did you also search for 44 4F 53 03 00 00 00 00 00 00? That's the international FFS partition type/ID. Your lost partitions may well be of that type if you used HDToolBox's default options. You can add more zeros to that search string if you want, since you're searching for a 512-byte block where all except the first 4 bytes are zero.

I also did a quick search for 44 4F 53 01 00 00 00 and I found five instance of this in the image file at the following lines:

0007e000
003f0400
le94cc00
5a373a00
6c3ec00

Now I just have a question and I promise this is one of the last ones before giving up; How do I determine Cyl (for LowCyl and HighCyl) from the line numbers? Or it is not something that strait forward?

It is fairly straightforward. And don't give up, just when you might be getting somewhere.

Now the 44 4F 53 01 signature is for a standard FFS (non-international) partition. That might be a remnant from when you partitioned the card differently in the past. So this isn't necessarily the start of the partition you want to find, but...

I'll start with the $7E000 one. That's a likely start-of-partition point since it's near the beginning of the CF card. Check again there, are the rest of the bytes (to offset $7E1FF) all zero?

$7E000 hex is sector $3F0 = 1008 (you divide $7E000 by 512 to get the sector number).

If that is the start of a partition, because it starts on a cylinder boundary that suggests there are 1008 or maybe 504 sectors per cylinder (for the partition to start at cylinder 1 or 2).

In summary, to continue working on this I'd suggest:
- Try to remember your previous partition layout. Are you certain what filesystem type the partitions used (FFS or FFS international)? Roughly how big was each partition?
- Also search for 44 4F 53 03 00 00 00 00 00 00 00 00 00 00 00
- Note down the positions where that string appears. Only ones with positions a multiple of 512 are relevant.
- If you remember roughly how large each partition was, that can help narrow the possibilities down further. For example if your first partition was about 500MB, then the start of the 2nd partition will be about 500MB into the image file. So concentrate on any search matches around there.

[thomas]

Originally Posted by Sim085

Hi thomas, tried it out but gave me an error message "Program Failed (error #80000005) Wait for disk activity to finish" (screenshot attached).

Fixed.

[Sim085]

Hello, thanks for the explanation. I have read the last two posts over and over again to make sure I am understanding everything correctly.

My understanding is that once I find all DOS/1 locations; then to get the first partition working becomes just a matter of combining the first DOS/1 with every other DOS/1 until one of them works. Am I right?

The first DOS/1 I found was at location 0007e000. Therefore;

0007e000 / 200 = 3F0
which to Decimal = 1008
which divided by 504 = 2

The next DOS/1 I found was at location 5a373a00 (ends with two 00 and third character from last is 'a'). Therefore;

5a373a00 / 200 = 2D1B9D
which to Decimal = 2956189
which divided by 504 = 5865

Therefore,

lowcyl = 2
highcyl = 5865 -1 = 5864

So next step is to write the mount file. I came up with the following:

Device       = uaehf.device
Unit           = 3
FileSystem	= L:FastFileSystem
Flags		= 0
Surfaces	= 1
SectorsPerTrack	= 1
SectorSize	= 504
Mask		= 0x7ffffffe
MaxTransfer	= 0x100000
Reserved	= 0
Interleave	= 0
LowCyl		= 2
HighCyl		= 5864
Buffers		= 5
BufMemType	= 0
StackSize	= 1000
Priority	= 10
GlobVec		= -1
DosType		= 0x43443031

I kept default values as CD0 for most of the things (do not know if that is right). Also I noticed that the incon information defined "Device" and "Unit". I looked on the internet and I found that some people put these in the mount file itself.

When I enter the command Mount HDA (I named the file HDA) I get nothing! (not an error message nothing). So I wonder if my mount file is correct.

Fixed.

I will test it this evening.

[thomas]

SectorSize is always 512 as discussed above. (The words "blocks" and "sectors" have the same meaning in this context. HDToolbox uses "blocks" where Mount uses "sectors".)

Surfaces * SectorsPerTrack should equal blocks per cylinder aka 504.

So Surfaces = 1, SectorsPerTrack = 504 would do as well as Surfaces = 8, SectorsPerTrack = 63 or other combinations. ("Surfaces" is the same as "Heads".)

Reserved should be 2 for FFS.

MaxTransfer should not be higher than 0x20000 or 0x1fe00 for CF cards.

Buffers should be set to at least 30, better 80 for harddisk partitions.

Originally Posted by Sim085

I get nothing! (not an error message nothing).

Add Activate=1 or Mount=1 to the mount file, otherwise it is only activated when you first access it.

Try CD HDA: or DIR HDA: to access it and eventually get a meaningful error message.

[mark_k]

Originally Posted by Sim085

Hello, thanks for the explanation. I have read the last two posts over and over again to make sure I am understanding everything correctly.

My understanding is that once I find all DOS/1 locations; then to get the first partition working becomes just a matter of combining the first DOS/1 with every other DOS/1 until one of them works. Am I right?

In the usual case where the second partition immediately follows the first that should work.

However, note that there can be false positives. By which I mean... suppose you partitioned your CF card in the past using WinUAE. Then later you re-partitioned it using your real Amiga. The exact positions of the partitions will vary, meaning that when you later search for DOS\1 (or DOS\3) strings in the image file, you find both "sets", the first corresponding to the old WinUAE-created partitions and the second corresponding to the later real-Amiga-created partitions.

Originally Posted by Sim085

The first DOS/1 I found was at location 0007e000. Therefore;

0007e000 / 200 = 3F0
which to Decimal = 1008
which divided by 504 = 2

The next DOS/1 I found was at location 5a373a00 (ends with two 00 and third character from last is 'a'). Therefore;

5a373a00 / 200 = 2D1B9D
which to Decimal = 2956189
which divided by 504 = 5865

Therefore,

lowcyl = 2
highcyl = 5865 -1 = 5864

So next step is to write the mount file. I came up with the following:
[mount file text omitted]
I kept default values as CD0 for most of the things (do not know if that is right). Also I noticed that the incon information defined "Device" and "Unit". I looked on the internet and I found that some people put these in the mount file itself.

When I enter the command Mount HDA (I named the file HDA) I get nothing! (not an error message nothing). So I wonder if my mount file is correct.

Thomas mentioned a couple of things which you should change: SectorSize and possibly MaxTransfer (though your setup of connecting CF to an IDE-SCSI converter and to your IVS SCSI controller won't need the same $1FE00 limit as the Kickstart IDE driver).

You need to change DosType to 0x444F5301 (for FFS). If you have the same keywords in both the icon tooltypes and text file make sure they either match or delete one of them. It's probably easier for testing to delete all the tooltypes.

When you search your image file for 44 4F 53 03 00 00 00 00 ... are there any results?

With the start and end sector numbers you gave, that means this possible partition has size of about 1.4GB. Do you remember having a first partition of that size before? If not, then "this isn't the partition you're looking for".

With FFS partitions, the FFS root block is in the middle of the partition. So for a 200MB partition for example, the root block would be 100MB into the partition. You can use that as a sanity-check on any potential partition. Use the hex editor to see whether there is something that looks like an FFS root block in the middle of the partition.

[Sim085]

Again I read the last two posts and updated the mount file as follows

Unit			= 3
Device		= uaehf.device
FileSystem		= L:FastFileSystem
Flags			= 0
Surfaces		= 1
SectorsPerTrack	= 504
SectorSize		= 512
Mask			= 0x7ffffffe
MaxTransfer	= 0x20000
Reserved		= 2
Interleave		= 0
LowCyl		= 2
HighCyl		= 5864
Buffers		= 30
BufMemType	= 0
StackSize		= 1000
Priority		= 10
GlobVec		= -1
DosType		= 0x444F5301
Mount		= 1
/*Activate   	= 1*/

When I enter "C:Mount HDA" followed by "CD HDA:" I get nothing. Should I be getting an error message? I just want to confirm the mount file is ok so that I can continue with the other combinations.

Originally Posted by mark_k

When you search your image file for 44 4F 53 03 00 00 00 00 ... are there any results?

Yes, but the first entry I found is like 10% into the image file and therefore I ignored it (I would have never just not used 10% of the CF card at the start).

I attached a screenshot to show my results.

[mark_k]

My mount file skills are a little rusty, but does it make a difference if you do Mount HDA: FROM HDA (assuming you named your mount file HDA)?

[Sim085]

Originally Posted by mark_k

My mount file skills are a little rusty, but does it make a difference if you do Mount HDA: FROM HDA (assuming you named your mount file HDA)?

I get an error message:

Error Device 'HDA:' not found in file 'HDA'

[thomas]

Is FastFileSystem present in L: ?

Is Unit = 3 correct? I get the same error message (HDA is not a directory) if I do not add a CF / HDF / whatever to WinUAE so that uaehf.device unit 3 does not exist.

[mark_k]

Originally Posted by Sim085

I get an error message:

Error Device 'HDA:' not found in file 'HDA'

I think that means you need to add HDA: as the first line of your mount file. However, if the mount file's name is HDA then doing Mount HDA should work. Note that if the HDA file isn't in the current directory you need to specify the path to it. For example if the HDA mount file is in RAM: you would do Mount RAM:HDA.

You should be able to omit the FileSystem line in the mount file, then the Amiga will use the ROM FFS.

[Sim085]

Originally Posted by thomas

Is Unit = 3 correct?

That was my mistake, now when I enter CD HDA: I get an error message "Not a DOS Disk in device HDA" (screenshot attached) ... I guess this means that I just got the end partition bad and I have to try another one!

Originally Posted by mark_m

You can use that as a sanity-check on any potential partition. Use the hex editor to see whether there is something that looks like an FFS root block in the middle of the partition.

How does that look like?

[thomas]

Originally Posted by Sim085

I guess this means that I just got the end partition bad and I have to try another one!

It could be that or something else. There are many parameters in the mount file which must match exactly how the partition was defined before. For example you omitted the SectorsPerBlock parameter. If you changed the fíle system block size from 512 to something else, SectorsPerBlock needs to be defined to that value (for example if you changed the block size to 1024 SectorsPerBlock needs to be 2). That's just one example.

How does that look like?

It contains the volume name.

Originally Posted by Sim085

I will test it this evening.

Did you try RDBRecov yet?

[mark_k]

Originally Posted by Sim085

That was my mistake, now when I enter CD HDA: I get an error message "Not a DOS Disk in device HDA" (screenshot attached) ... I guess this means that I just got the end partition bad and I have to try another one!

Could be. You mentioned that when you search for the 44 4F 53 03 00 00 00 ... bytes you found one about 10% into the disk. Could you have created a ~200MB FFS partition followed by a larger FFS international partition before?

Taking your possible partition as an example... the partition occupies byte positions $7E000 to $5A3739FF in the image file.

But I see something wrong there. The sector after the end of the partition is an odd sector number. But if that sector is the start of the next parition, it should be a multiple of 504 for your fake geometry to be correct! That means the end of the partition is wrong.

I'll try to write something more detailed about how to search for possible root blocks. But try looking for this byte sequence, appearing on a 512-byte boundary in your CF image file:
00 00 00 02 00 00 00 00 00 00 00 00 00 00 00 48 00 00 00 00
And the last four bytes in that 512-byte block should be: 00 00 00 01

For a 1024-byte-block partition, instead of 00 00 00 48 in the string above, you would have 00 00 00 C8.

[Sim085]

Originally Posted by thomas

Did you try RDBRecov yet?

Hi thomas, tried it right now (this is with the A500+ with GrandSlam and SCSI to IDE, IDE to CF adapter as I still do not have cable for the A1200).

I attached a screenshot of the result. It seems it did not find any partitions! Could it be because of the values I used for s, c and cs?

I used the values returned from HDToolBox as from WinUAE.

[thomas]

Originally Posted by Sim085

Could it be because of the values I used for s, c and cs?

Most likely. By your manual attempt you found out that one partition possibly starts in block 1008. With the cs value you specified, it can never reach that block. Try cs 504 and c 7939.

[Sim085]

Originally Posted by thomas

Most likely. By your manual attempt you found out that one partition possibly starts in block 1008. With the cs value you specified, it can never reach that block. Try cs 504 and c 7939.

Hello, sorry for late reply but was unable to try anything because did not have access to the amiga. I tried what you told me and I get the following output (screenshot also attached):

Possible FFS Bootblock found at cylinder 2: DosType=444F5301
Ready cylinder 7939
Checking FFS partitions
Complete

When I restart nothing happens.

Could this be because of I had previously used RecoRDB IVF_SCSIpro.device 0 rebuild on the CF card?
(see post 28)

If yes, then is it possible to re-write the original image I did with WinUAE back to the CF card so I can try again? or recovering files from the CF card is now out of the question and the only option I have is the image file itself? i.e. using WinUAE.

[thomas]

I have to admit that I don't remember where I got 504 / 7939 from. It does not fit. Your former screenshot shows c 992 cs 4034 which means the drive has 4001728 sectors. With 504 / 7939 it would have 4001256 sectors. This does not fit.

Please try the attached new version of RDBRecov. It will peek the drive for its number of sectors and then fake a reasonable geometry if TD_GETGEOMETRY is not supported.

First run it like this:

rdbrecov IVS_SCSIpro.device 0 info

and quote the printed values here, just to make sure that 4001728 sectors is correct.

Then run it like this:

rdbrecov IVS_SCSIpro.device 0

It should select a CS value of 16. It will probably take quite some time to read the entire disk in steps of 16 sectors. But it should find at least two "possible FFS partitions". And with a bit luck two of these "possible FFS partitions" will then be checked and confirmed as "real" FFS partitions.

No, RecoRDB did not do any harm to RDBRecov. RecoRDB examines the partition table only. RDBRecov ignores the existing partition table completely and searches partitions on the entire harddrive. These are two different approaches which don't influence each other.

Please also note that RDBRecov does not do any repair action. It only prints to the console what it found. You have to recreate the partitions yourself with HDToolbox. RDBRecov just tells you what you have to enter into HDToolbox (once it found something useful).

[Sim085]

Originally Posted by thomas

Please try the attached new version of RDBRecov. It will peek the drive for its number of sectors and then fake a reasonable geometry if TD_GETGEOMETRY is not supported.

First run it like this:

rdbrecov IVS_SCSIpro.device 0 info

and quote the printed values here, just to make sure that 4001728 sectors is correct.

I attached screenshot. I get "TD GETGEOMETRY ERROR = 45. (status and or sense error)". Note I made sure I downloaded the latest attached version and indeed placed it in another folder to confirm I am using the latest version of RDBrecov attached in the previous post.