I am so sorry for that post of mine.

Don't worry , it can happen to anyone.

And it wouldn't really cause any "big" issue, since the (fd0,0) partition should start on LBA 2048.

@Misty

You are putting in my (educated) guess too much confidence, those ranges are too narrow, as well as the suggestion by tinybit (set aside the mistake between (fd0) and (fd0,0) ) was "wrong" in the sense of being composed of "fixed" steps, the x10 between 1 and 10 is 9 sectors (too few) the x10 between 10,000,000 and 100,000,000 sectors is 90,000,000 sectors (too many).

devdevadev (that insists on senselessly posting the second screen of the result ) hit the outside of the partition at 100,000,000 sectors, i.e. roughly 48 GiB, which is normal, since the partition is 29 GB in size, but when he used the USB stack/driver in 0.4.6a he found the actual blocklist start address of the file (relative to (fd0,0):

27293088, and since that address could not be reached before, that is clearly already beyond reach (and thus it makes no sense to probe for higher than 27,293,088 values).

The "right" way to find an unknown limit (setting aside my guess) is to use a "converging" algorithm.

We know that limit "x" is:

0<x<27293088

We can take for simplicity a slightly higher "rounded" value, 28,000,000

and have:

0<x<28,000,000

then you try for the first term + half the difference:

0+(28,000,000-0)/2=14,000,000

so you test:

cat --hex (fd0,0)14000000+1

which equates to:

0<x<14,000,000

IF you have the error, than you half again:

0+(14,000,000-0)/2=7,000,000

and check that:

0<x<7,000,000

IF you don't have the error you are now in:

14,000,000 < x < 28,000,000

now you half again the difference and sum it to the lower limit:

14,000,000+(28,000,000-14,000,000)/2=21,000,000

and check that:

14,000,000<x<21,000,000

and so on...

Wonko