Version 0.10 r238: Cannot format drive with FAT32

[erdmann]

When I attempt to format a USB stick partition with FAT32 I get this error ad infinitum:

SYS0027: The drive cannot find the sector (area) requested.

[erdmann]

Don't know if that makes a difference: it's a "large floppy" emulated FAT32 partition.
I can use DFSee to format that partition with FAT32.

[Valery V. Sedletski]

Large floppies did not tested so far, so it may be the cause. Partitioned media should work. Need to test it in the nearest time.

[Valery V. Sedletski]

Tested big floppy media. It work for me now (please, update to r241, see http://trac.netlabs.org/fat32/), since I added DSK_GETDEVICEPARAMS with getting recommended BPB, if no real BPB present. I see no "sector not found" errors, but I had FAT corruption errors before that. Now it seems to work stable for me. Please, test.

PS: If I wipe the disk beginning with DFSee, and then try to format it, I get "cannot set partition type in partition table" error, because Hidden sectors is not initialized. (I subtract HiddenSectors from partition starting offset, to get the MBR/EBR sector). But if I replug the flash stick, FORMAT succeeds.

[erdmann]

This is what I get with r241:

[d:\]format c: /FS:FAT32
FAT32 version 0.10.r241 compiled on Apr 19 2017
The new type of file system is FAT32.
The disk has no volume label.
Warning!  All data on hard disk c: will be lost!
Proceed with FORMAT (Y/N)? Y
ERROR: Failed to begin format device
SYS0528: The specified disk did not finish formatting.
SYS0252: The specified file system name is incorrect.

EXPLANATION: The specified file system name could not be found.

ACTION: Do one of the following:
o  Retry the operation using the correct file system name.
o  Add the IFS= statement (containing the correct file system name)
   to the CONFIG.SYS file and restart your system.
o  Contact the supplier of the application.

Error code: 252

[erdmann]

Oops. Ignore the last comment.

[erdmann]

With r241 I get the very same error that I already stated.
Note: What the "large floppy" emulation in USBMSD.ADD does is also emulating the very first sector in the "partition". It has to prevent alteration of this sector because that could heavily screw up the virtualization. However it correctly "emulates" the "hidden sectors" field to skip the virtualized sectors preceding the actual "partition".
I don't know what your FAT32.IFS does. It definitely should NEVER try to read/write ANYTHING outside of its own partition (where admittedly the aforementioned sector actually falls within the partition).

[Valery V. Sedletski]

It writes the partition type field in partition table, as it should do. It avoids to do it on GPT disks, but I have no idea, if I should detect your big floppy somehow. I suspect, no, because it works fine on my machine. On yours it fails to begin format, for some reason (please, take a f32mon log, maybe, it will become clear then).

[Valery V. Sedletski]

Lars, how do you emulate hidden sectors? I have an exFAT disk, and see the hidden sectors filled on it too. But with exFAT, the BPB is empty (zeroes). So, you emulate boot sector access too?

[erdmann]

USBMSD.ADD: I think you should have access already, so look at:
​http://trac.netlabs.org/usb/browser/basedrv/branches/lars/usbmsd/msdio.c[[BR]] for a routine "ChkAndPrepForLargeFloppy". Then, there is a another large floppy relevant spot in the very same file in routine "ExecuteUSBIO" for IOCC_EXECUTE_IO command.

I don't understand what you mean with "emulate boot sector access". To be honest, I would need to look into my code in more depth ...

[erdmann]

Just had a look:

(VBR: "Volume Boot Record", first sector in a "partition"/"virtual partition")
("virtual partition": the original complete large floppy media, emulated to look like a partition)

1) USBMSD.ADD emulates the MBR, the VBR and the DLAT sector

2) USBMSD.ADD will always prevent writing into ANY of the sectors preceding the "virtual partition", in particular it will prevent writing to the emulated MBR and the emulated DLAT sector. Additionally it will prevent writing to any of the other emulated sectors preceding the "virtual partition". That's because messing with emulated MBR or DLAT sector would likely lead to catastrophic failure of the emulation. As to reading from these sectors, it will return the emulated MBR, the emulated DLAT sector, for any other sector it will return all zeros.

3) for large floppy media, USBMSD.ADD will write the partition type field all by itself into the emulated MBR, either the IFS_INDICATOR (0x7, for exFAT) or the FAT32X_PARTITION_INDICATOR (0xC, for FAT32).

4) USBMSD.ADD WILL write a few BPB fields (BigTotalSectors, BytesPerSector, HiddenSectors, NumHeads, SectorsPerTrack) of the emulated VBR even for exFAT. I seem to remember I did that because OS/2 knows nothing about the new MBR layout for exFAT formatted media and will be unhappy if it does not find at least these few fields of the legacy BPB layout. It's all OS/2's fault :-)

Please note that exFAT support in USBMSD.ADD is the bare minimum to allow peaceful coexistence with DFSEE to show a large floppy exFAT formatted USB stick as such in DFSEE. It does NOT read/write files or directories and it knows nothing of the exFAT filesystem layout.

[Valery V. Sedletski]

​http://trac.netlabs.org/usb/browser/basedrv/branches/lars/usbmsd/msdio.c%5B%5BBR

I cannot view this source, because I have no access to it (it asks for a password again)

I don't understand what you mean with "emulate boot sector access". To be honest, I would need to look into my code in more depth ...

I mean, you change HiddenSectors and other fields somehow. You probably, create the copy of a boot sector, and change it, instead of an original one?

USBMSD.ADD will always prevent writing into ANY of the sectors preceding the "virtual partition", in particular it will prevent writing to the emulated MBR and the emulated DLAT sector. Additionally it will prevent writing to any of the other emulated sectors preceding the "virtual partition".

That's bad, because every FORMAT version (including HPFS and JFS, and FAT32 too) writes a partition type byte into the partition table entry (0x7 for exFAT or NTFS or any OS/2 IFS, 0xb or 0xc for FAT32, 0x1/0x4/0x6 for FAT). It will fail to do so, and display an error. Also, I suspect that you do a boot sector emulation too (for Hiddensectors etc.). So when FORMAT tries to write fields to BPB, it could fail too.

Finally, in order to "revert back" a large floppy emulated media back into a state where it can really be partitioned, it will look at the VBR. If this VBR is all zeros, it will "turn off" the emulation. The idea is to write all zeros to the VBR via DFSee (for example). Once you did that you can then use LVM to do a real partitioning of the media.

And DFSee could write zeroes (or 0xf6 symbol too, not only zeroes. It is checked by the OS/2 kernel that the structure is erased with this symbol, to be invalid), over all drive, not only partition.

And, why exFAT support in USBMSD.ADD? So, you check for a filesystem type in USBMSD.ADD? It should be a filesystem independent, so USBMSD should not know of any filesystem. You can only set the partition byte to 0x7 for any filesystem. At least, fat32.ifs can mount the filesystem, regardless of this byte (not sure of IBM's in-kernel FAT driver, but I suspect, it will take any value too).

PS: You still need to take a f32mon log when you cannot FORMAT the big floppy removable. BTW, Does it mount the big floppy at this moment? Does fat32.ifs work at all for other media (partitioned USB ones, and fixed disk partitions)? Please run f32mon.exe before you attach the flash disk, to include FS_MOUNT call into the log.

[erdmann]

I don't know what you want to tell me:

1) you cannot properly repartition/format/change fs indicator a "large floppy" emulated disk. You have to revert "large floppy" emulation first, then you can do whatever you want. Everything is EMULATED for a "large floppy" type USB stick. If the USB stick is really partitioned in the true sense of the word USBMSD.ADD will not prevent writing the MBR.

2) there is no exFAT filesystem support in USBMSD.ADD. It is only there so that when emulating "large floppy" I can distinguish between FAT/FAT32 and exFAT formatted large floppy type USB sticks because all these filesystem allow to be used with "large floppy". Any other filesystem needs true partitions. USBMSD.ADD knows NOTHING (I repeat: NOTHING) about the layout of the data on a partition.

[Valery V. Sedletski]

But it is legal for FORMAT program to change partition type field in MBR. It is done by HPFS/JFS FORMAT too. So why not allow to write there? If I only change the partition type, nothing will happen. In the worst case, if MBR will be destroyed, the FS will not mount and nothing will happen. And, you can notice if the partition is zeroed-out and invalidate the MBR sector too. And why restrict big floppies to FAT/FAT32/exFAT? HPFS big floppies should work too. And BTW, in Linux, you can have even a hard disk without a partition table, and mount as a whole. Indeed, no difference between a flash disk and a hard disk. If not FAT-based FS, you can set partition type indicator to 0x7 (IFS), then any FS may be used on a big floppy. In fact, I suspect that you can set partition indicator to 0x7 for all FS's and it should work.

PS: in FORMAT, I see hidden sectors != 0 on USBMSD.ADD-emulated big floppy, so I decide that it is partitionable media, because the boot sector is not the 1st one. So, it is quite legal to access MBR and write there. And, I have no means to distinguish between emuulated and non-emulated media, so I cannot decide if I need to avoid writing to the MBR. So, it would be better to allow wirting there.

PPS: BTW, on my machine, writing to MBR seems to work. I don't see any errors when running FORMAT or CHKDSK. And I tried to wipe by zeroes the whole emulated harddisk, not only the partition, with dfsee and it works fine for me. I don't know what is not working on your machine, and why. So, we need to make it clear. The 1st thing we need is to take a log when you trying to format the disk.

[erdmann]

I rechecked my USBMSD code: it will support overwriting MBR, DLAT sector and also the VBR, therefore no error should occur. But don't expect any of that to be sticky. As I said, for "large floppy" these sectors only exist in memory.

It is useless to support HPFS and JFS as "large floppy". "large floppy" emulation was done to be able to handle such media created under Windows.

[erdmann]

Tested SVN rev 299 and FAT32 formatting works ok with a USB stick.