Rod Pemberton wrote:
> "Alexei A. Frounze" <alexfru@[EMAIL PROTECTED]
> wrote in message
> news:fY2dnaY9jp05P8vYnZ2dnUVZ_qWdnZ2d@[EMAIL PROTECTED]
>> Rod Pemberton wrote:
>>> Does anyone know of a DOS/Win98 utility to "mount" a filesystem
>>> image (loopback?) or cause the image to be accessed as if it is a
>>> drive under DOS (like a ramdisk)?
....
>> What do you want that for? To create a disk image with some files in
>> it for the use with the OS? Or do you want to test your FAT code on
>> such an image? Both?
>
> Basically... I have additional hard drives, but I'd prefer not to
> have to install them just to do preliminary FAT12/16/32 partition
> tests. It's easy to do in Linux, but I (currently) need DOS or
> Win98. With the Windows mkdosfs, half the problem, creating
> FAT12/16/32 images, became really easy. But, you also need a way to
> mount them (?), copy files (mtools?), etc... I could copy the images
> into memory and then run the code against the memory (like a custom
> ramdisk) but I'd much prefer to find a utility or driver or ramdisk
> code.
Well, I, for one, don't copy files to the images in order to test the FAT
code. Instead I create files and dirs with my FAT code right there, in the
images. Of course, if your code is read-only, that will not work for you
--
you'll have to have something in the image prepared by other means.
>> For the testing purposes I wrote a rather dumb application that
>> creates for me two complete HDD images:
>> 1st:
> <snip>
>> 2nd:
> <snip>
>> The images contain proper MBRs, bootsectors and initialized FATs,
>> where the only missing things are: code in MBRs/boot sectors and CHS
>> values in MBRs. I don't use those and so I don't compute and put
>> them in.
>>
>> I ran my FAT unit test with these images mounted.
>
> How?
In my implementation the disk read and write functions are callbacks. And
when I'm testing I'm just susbstituting file read and write functions
instead of disk read and write functions. So, mounting isn't quite
mounting,
the disks don't appear in DOS or Windows, they appear in the test
application and it works with those as files w/o even knowing that or
caring
about that. That's the proper way of doing it. Yeah, I admit I first wrote
an application that worked with the disks directly and only then made a
file/image-based test, but in reality, one should first test in simple
environment with all debugging tools and then if that works move to the
real
environment. Back to the FAT FS module, though... It provides the
following
high-level functions:
FAT_getcwd, FAT_chdir, FAT_dos_getdrive, FAT_dos_setdrive,
FAT_fopen, FAT_fclose, FAT_fflush, FAT_unlink,
FAT_fseek, FAT_rewind, FAT_ftell, FAT_feof, FAT_fsize,
FAT_fread, FAT_fwrite,
FAT_opendir, FAT_closedir, FAT_rewinddir, FAT_readdir,
FAT_mkdir, FAT_rmdir
FAT_access, FAT_stat, FAT_chmod, FAT_utime
FAT_statvfs
So, one can read/write files from/to the disk image almost the same way as
with the standard C functions on the host OS's FS. I guess, that's what
you
wanted in Ben's mtools package, but didn't find there everything.
>> Seems like with this unit
>> test and these images I cover over 80% (as per gcov) of my FAT code.
>> Which is a quite good number given the fact the code that isn't
>> covered is mostly this:
>> - I/O error handling
>> - FAT error/corruption handling -- honestly, I don't plan to make
>> the code unbreakable or make FAT checking/fixing tools
>> - floppy changes -- requires a model of a floppy drive, just file
>> I/O isn't enough to test this functionality automatically, the same
>> applies to I/O error handling too -- this is a testability issue
>> - big files (4 GB) -- also a testability issue -- a 4GB file needs
>> an image bigger than 4GB, which means that the image must be
>> scattered across several files of size under 4 GB or whatever the
>> host OS or standard library has the limit for file sizes
>> - redundant parameter checks
>> - some redundant (general-purpose) code
>>
>> If you're interested in testing FAT code or playing with mine, stay
>> tuned, I'm gonna release an updated version soon with the test
>> suite. Automatic testing and code reviewing prove useful as they
>> have revealed 5+ more bugs, which isn't a big surprise for 5000+
>> lines of code.
>
> Thanks, will wait.
I have a couple of things to check and maybe change and then try out the
latest Open Watcom (1.6). Seems like there's a lot of stuff in OW that's
broken or that gets broken and doesn't have enough regression tests. Bugs
in
the compiler are scary and nasty... I have some compiler bug at work
that's
breaking code...
Alex
|
