Some .img files fat12 can not be open

A free file archiver for extremely high compression

Brought to you by: ipavlov

Some .img files fat12 can not be open

Forum: Open Discussion

Creator: xj900f

Created: 2012-08-08

Updated: 2012-12-07

xj900f - 2012-08-08

Hi,

Most of floppy backups I made (raw img then zipped) for years are directly readable in 7zip, which is a very nice and comfortable feature.

Unfortunately it seems if "jump" value at second byte of first sector of img file is not "3C", 7zip can not handle it, I have to use another tool.
If I patch this byte with hexa editor forcing 3C, 7zip can open it (but the boot sector becomes corrupted, so I do it on temporary copy). It seems 7zip just uses the 3C value to validate the file.

I think 3C is the most common value because used by recent DOS format command, but disks from other sources (Games editors, PC Tools, pkzip multidisk) seems to commonly use 3C or 34 values too. I can found a few 24, 28, 29 too.

Then is it possible to replace the single 3C check by a range check(24 to 3C seems enough from my experience, but not sure…)?
Or simply just check the 1rst and third bytes are "eb" and "90"?

Thanks

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Igor Pavlov - 2012-08-09

Can you upload examples of such FATs to some server?

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

xj900f - 2012-08-09

Yes, it is here: dl.free.fr/v3fUhksKI (sorry for the delay it was longer than I thought to prepare it).

I put some examples with different cases I found, just overwriting the data part with same content (for smaller size and copyrights reasons on some softwares).

In the zip I put the .img files in respectively \\\"eb3c90\\\", \\\"eb3490\\\", … folders according the 3 first bytes of the .img.
As you will see, we can open easily explore the \\\"eb3c90\\\" img files from 7zip browser, but not others.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Ady - 2012-08-09

@xj900f

I took a look at one of those images, DISK_3.5 -> eb2a90.

I don't know how you built it and which characteristics SHOULD have, but if it is supposed to be a FAT12 floppy image, then it is completely wrong, so it is no surprise that 7-zip can't open it.

That specific image size is 1440KiB, but the data corresponds to a 720KiB floppy. In addition, at least the second FAT is located in the wrong sector of the image, and the last cluster contains "0x00" instead of "0xF6".

There might be additional issues, but I stopped checking because I'm not sure how you built those floppy images. It is not just about changing to "3C".

You would need to provide more details, and/or re-build those floppy images correctly.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Ady - 2012-08-09

Re-reading my own post above, I think I should clarify.

The image I tested corresponds to 1440KiB, but the first sector contains info about a 720KiB image. Correcting the relevant fields to match a 1440KiB image (and a couple bytes more) the image works.

Then, by changing the jump code to "3C", indeed 7-zip opens the image. Without this last change, 7-zip still can't open it.

My point is that the image I tested is not a good example for Igor to evaluate it, because it needs not just the "3C" change but also additional corrections not related to 7-zip.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

xj900f - 2012-08-09

@ady-sf

I made the images with rawwritewin-0.7.

For SBI.1.img (eb2a90), RawWrite extracted a 1.44 file then I thought it was a 1440kB floppy. But you're are right, it seems to be a 720 kB. In this case I corrupted the image myself today when using its first sector and joined dir/files from a 1440kB to build the example.

Then I cheked other img and found same case with LEM.1.img and WOR.1.img: RawWrite outputed a 1440 kB file, but should more probably be 720 kB.

Other seems real 1.44 and are readable from VirtualBox and Extract2.1.

Then I remove the three 720 kB files from the zip, and upload it again there: dl.free.fr/nj1ALvpRF

I hope I didn't make other mistakes.

Thank you very much for your help.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Igor Pavlov - 2012-08-10

I don't know how to download from that french server.
Please upload to another server.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

xj900f - 2012-08-10

Have you access to this one?
www.sendspace.com/file/qibzwo

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Igor Pavlov - 2012-08-10

OK. I'll change the code to support these images. Thanks!

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Ady - 2012-08-10

@igor,

FWIW, FAT floppy images are usually expected to start with:
- EB nn 90
(or with - E9 nn nn )

where "nn" are hex numbers (but not necessarily the same in each position).

It would be very uncommon to find jump values as "EB 26 90" that would comply 100% with a FAT12 boot sector. For example, they probably would never be FAT12 bootable floppy images.

Still, the file system itself could contain readable files anyway.

HTH.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

xj900f - 2012-08-10

Fine, thank you very much Igor

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Log in to post a comment.