info-mtools
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Info-mtools] What does it take to support FAT12 dialects?


From: Alexander Huemer
Subject: Re: [Info-mtools] What does it take to support FAT12 dialects?
Date: Mon, 7 Jun 2021 09:35:40 +0000
User-agent: NeoMutt/20180716

Hi Alain!

On Sun, May 30, 2021 at 07:34:51PM +0200, Alain Knaff wrote:
> In today's 4.0.28 release I finally opted for introducing an option to
> remap the order of sectors in the image file. I.e. the upper layers of
> mtools will "see" an image where some sectors are skipped, some others
> filled in, and some used from the image.
> 
> This is done by specifying a data.map along with the image:
> 
> mdir -i ~/tmp/24.img\|data_map=1s,zero31s,28s,skip1s -a ::
> 
> A data map is a comma-separated sequence of source type and size. Source
> type may be "zero" for zero-filled sectors created by map, "skip" for
> data in raw image to be ignored (skipped), and nothing for data to be
> used as is (copied) from the raw image. Datamap is automatically
> complemented by an implicit last element of data to be used as
> is from current offset to end of file. Each size is a number followed by
> a unit: "s" for a 512 byte sector, "K" for Kbytes, "M" for megabytes,
> "G" for gigabytes, and nothing for single bytes.
> 
> Example:
> data_map=1s,zero31s,28s,skip1s can be used with IBM 3174 floppy images.
> 
> First sector ("1s", boot sector) is used as is.
> 
> Then follow 31 fake zero-filled sectors ("zero31s"). These represent the
> unused extra 31 reserved sectors that we saw specified in the boot sector.
> 
> Then follow the next 28 sectors from image ("28s"), these are used as is
> (they contain FAT and root directory).
> 
> Then, finally, one sector from image is skipped ("skip1s"). This is the
> because the physical floppies actually lack 30 sectors on first track
> (only 15 sectors instead of 30 per side). Ucode3174 skips that sector by
> enforcing that sneaky alignment constraint that I mentioned in one of my
> previous messages :-)
> 
> And finally the rest of the image is used as is (implicit)

Many thanks for this!

I did some testing, this seems to work as intended.
E.g.

> ~/src/_readonly/mtools/mtools-4.0.28/minfo -i 
> /tmp/24.img\|data_map=1s,zero31s,28s,skip1s

> ~/src/_readonly/mtools/mtools-4.0.28/mdir -i 
> /tmp/24.img\|data_map=1s,zero31s,28s,skip1s -a ::

> ~/src/_readonly/mtools/mtools-4.0.28/mcopy -i 
> /tmp/24.img\|data_map=1s,zero31s,28s,skip1s -a :: .

The parameters of the command below were suggested by `minfo`.

> ~/src/_readonly/mtools/mtools-4.0.28/mformat -C -T 4800 -h 2 -s 30 -H 
> 1710948352 -i "/tmp/foo.img|data_map=1s,zero31s,28s,skip1s" ::

What I did not yet figure out is how I can write all files in a local 
directory (e.g. from a previous `mcopy` call from an images file to the 
disk) into an image file. This probably has little to do with the 
data.map but is simple lack of understanding on my end.

I tried this:

> ~/src/_readonly/mtools/mtools-4.0.28/mcopy -i :: * 
> /tmp/foo.img\|data_map=1s,zero31s,28s,skip1s

But get this response:

> File "/tmp/foo.img|data_map=1s,zero31s,28s,skip1s/AEAOTHER.PUR" exists, 
> overwrite (y/n) ?

The image definitely has no content. It didn't exist before I created it 
with `mformat`.

What am I doing wrong here?

-Alex



reply via email to

[Prev in Thread] Current Thread [Next in Thread]