Re: DOSdosfsck 2.8.0 beta release! ... - state of the port

Hi Alain et al,
thanks to the great compatibility of DJGPP to its brother (sister?) GCC,
the DOSFSCK port is already "quite useful" (aehm...).

Just as DOSFSCK for DOS, it can check a filesystem in any image file
or device that you tell it to check on the command line.
It has the full functionality of the Linux version and it does run
in Dosemu and (with DPMI) in FreeDOS (so it is incompatible to FD emm386
for the moment).

The problem is that the only useful devices that DOS offers are CON and NUL,
so to say. So while you could scan, simply said, /device/harddisk1/partition1
(okay, Linux calls it /dev/hda1) without any troubles in Linux, there is
no such device system in Dos.

So in the current state (unless you find a cool TSR driver that emulates
Devices like "DISK$C" or something in DOS style), you have to use disk
imaging tools like raread/rawrite to create an image of the filesystem,
check/fix it, and write it back if needed. The good point is that you cannot
break anything apart from the image file in the current version!

The big PROBLEM, to repeat it, is that DOSFSCK cannot yet access the raw
PARTITION directly. Only image files.

To fix the problem, according to feedback from Tom and from the current
DOSFSCK for Unix maintainer, the plan is as follows:

IO.C should be changed to detect whether you give a filename (image mode)
or a drive name (partition mode) as target of fs_open. Then, fs_read,
fs_write and fs_seek (and probably others) should have some code added
that does the normal image/Linuxdevice stuff for image mode, but calls
sector read/write functions for partition mode. Because the BIOS "solution"
of the e2fstools Dos port (e2fstools check and create Linux ext2 file-
systems) is such a kludge, we all agree on using DOS SECTOR ACCESS
functions for the sector read/write module (which should become
a separate file from IO.C, but gets called by IO.C). The problem is
that DOS has THREE different APIs for that: FAR CALL (no INT) to
where int 0x25/0x26 point with either REGISTERS (< 32 MB partition
size) or a STRUCTURE (> 32 MB partition size) used to pass on the
selection of sector number, read/write number of sectors and buffer
position, or as THIRD a DOS (int 0x21) call that has to be used for
FAT32 partitions.

As if this would not be entertaining enough, each of the 3 interfaces
must be accessed from protected mode, so you have to use special
transfer buffers (__tb or a buffer you allocate yourself) beyond the
1 MB boundary to communicate with DOS, and DPMI functions to do the
call far / int to the DOS 16bit world. I have collected and sent a
list of useful URLs, mostly pointers to http://www.delorie.com/ FAQ
and LIBC description, in one of my previous mails to fd-dev. This
should help a lot (the mail also contains cut and paste of the relevant
parts of all 3 interface specs for DOS sector-wise drive access).

So we have different tasks to be done (somebody else this time, not me?):
- add the "translate to and call sector based access if parttion mode"
  to IO.C
- write three different implementations of sector based read/write as
  explained above
- decide based on partition size and type which of the three gets used
  when the "sector based read/write".C gets called from IO.C

Should be possible to split this work to several people it you want to.

Thanks for testing and improving the package. I think that the maintainer
of the Unix version has made my patches a bit more readable/compatible in
the meantime, so if you want to help with programming, maybe get a nicer
version from him first (its the one that I cc: in this mail ;-)).

Eric

Alain wrote:
> I am very interested in  DOSFSCK's port.
[great!]
> I just could not clearly understand tha stage of completion!
[complete for images. lowlevel disk access driver missing]
> Is it ready for test? can I run it in a freddos system ?
[Yes and yes, but it only processes image files yet. Y'know full.bin etc.]
> What is ready and what is not? 
[Ready to rumble, but only on images. With some DJGPP wizard at hand,
 the missing feature of accessing drives and not only images should be easy]