Short: V2.14 Multi filesys+.device, w95+mac++ Uploader: msw@blackpool.ac.uk Author: frans (francis swift) Type: disk/misc Replaces: xfs.lha XFileSystem Version 2.14 Consisting of xfsd (a disk handler for your L: directory) and fd.device / file.device (for your devs: directory), and either mountlist.xfsd (for your devs: directory on WB2) or FD0 etc (for your devs:DOSDrivers directory on WB3). Current xfsd status: readdir read write delete rename readpartition format ql + + + + + spectrum + + msdos / w95 + + + + + + archimedes + + amiga + + + + + + minix + + + + + mac + + + cpm + + 1541 + + Current fd.device status: read write format Amiga tracks + + * Diskspare + mfm (pc etc) + + * diskspare style disks of 960k (80 track) only at present Current file.device status: read write format flat files + + dms files + pctask/janus hardfiles + + As you can see, there is currently no way to format disks. In fact, most of the code to format disks marked as writeable exists, it's just there's no way to select it at the moment. Actually, TD_FORMAT does work on fd.device, but only on disks already formatted (it effectively just writes). See the xfs.guide 'usage' section for further info. --------------------------- xfs214 ------------------------------ Completed MINIX handler. Of course there may be some hidden bugs so it should be considered just a beta version for now. Patched disk type into dl_DiskType. Only reason it hadn't been done till now was I thought I'd already done it. So now you will get sensible results from Stephan Rupprecht's Info program. Anyway, it gives me an excuse to explain the disk types that are returned. Amiga DOS\0 DOS\1 FFS DOS\2 Int DOS\3 Int FFS DOS\4 DC DOS\5 DC FFS MSDOS/W95 MSD\0 MAC MAC\0 Minix MNX\1 (and later maybe MNX\2) QL QL5A 720k (and ED disks) QL5B 1440k Spectrum ZXS\0 Disciple ZXS\1 UniDos ZXS\2 SamDos ZXS\4 Opus (180k) Archimedes ARMD ARME CP/M CPM\2 (and later ZXS\3 for Plus3Dos) C64 1541 (and later 1581) These will (eventually, NOT YET) be the dos types passed to the Format() command to select the file system. Also, the file.device has been updated to allow it to work better with devd (DEV:) so that you get the chance to select a file before the DEV: device asks if there's a disk (file) in the 'drive'. Now that I have some 1581 disks to experiment with I should be able to add handling of these to xfs. Since these disks use side skewing (quick explanation - the top is on the bottom), I will need to modify fd.device to accept this format. Also, although the physical sectors are 512 bytes, the logical sectors are only 256 bytes, which will make sector allocation complicated, so for the moment support will be read only. Finally I tidied up some clean-up routines so some random crashes on removal of disks should disappear. --------------------------- xfs213 ------------------------------ Added a couple of extra disk types to existing handler modules, specifically Archimedes D type disks, and Spectrum 180k (Opus Discovery) type disks. Note that both use unusual sector sizes, the Archimedes D using 1024 byte sectors, and the Spectrum 180k disks using 256 byte sectors (it's also 40 track single sided!). Luckily fd.device sorts all this out transparently. One more technical point. Whenever a disk is recognised by xfsd the disk dos type is now written into de_DosType in the environment table of the device entry in the dos list. This is to allow anyone using the Info() call (which xfsd implements like most handlers by returning ID_DOS_DISK in id_DiskType for disks it recognises) to access the true disk type. Updated crc utility to fix a slight bug. There's a slight change to the flags setting in the mountlists, which should be backwards compatible, see mount.xfsd. Up till this release it was possible to open directories as if they were files. This was a side effect of the internal implementation which took advantage of the file-like structure of directories in certain filesystems (QDOS,MSDOS,RISCOS etc). I left this in so it would be possible to write external utilities to access filesystem-specific information that would otherwise be inaccessible via xfsd. Unfortunately, there are too many badly written programs out there that, when given no file name on the command line, open the empty string by mistake. Of course, this means the current directory, so they get a 'wrong type' error. With xfsd, they would get no error, and depending on the way the filesystem sets the file size for the directory, may try to read the whole disk into memory, or 4GB, or any random number. Anyway I've disallowed this again. -------------------------- xfs212b3 ----------------------------- Just a slight update to file.device. I re-wrote the xDMS source to be re-entrant / thread safe ('pure' in amiga-speak), so now file.device, which uses the decompression routines from xDMS, can safely be opened multiple times for multiple DMS files. I'll probably upload the modified xDMS source with the next release of xfs. -------------------------- xfs212b2 ----------------------------- There was a slight bug in the previous file.device when using PCTask hard disk files. Basically, writing could trash them. This was a bug introduced during re-organisation to allow proper integration of DMS file access. Anyway, it should all work now, reading/writing PCTask hard disk files (apparently the same format as janus hard disk files), and reading DMS files. To implement the DMS facility I used the source from xDMS (by Andre de la Rocha) to replace my original routines (which called DMS externally). The current xDMS decompression source is still very similar to the original LhA decompression routines (written by Masaru Oki and Haruyasu Yoshizaki), which are not re-entrant, so at present you can only have one DMS file in use by file.device (ie only one unit of file.device can be accessing a DMS file - other units can still access other types of disk file). I have recently re-written these LhA decompression routines (for another project) to make them re-entrant, so the next release of file.device should allow any number of units to access DMS files. Hopefully, it should soon be possible to transparently access .ADZ files as well. There is a mis-match between the current version of the devio utility and the current release version of fd.device. This only affects the -geometry option, and is caused by a mis-match in the private structure used to pass back the low-level info (about sector numbering and skew factors). This will be fixed next time. Ther was a slight bug introduced by internal rationalisation of the utf-8 / unicode routines which caused QL comments (which hold task space info) to be messed up. Should be ok now. -------------------------- xfs212b ------------------------------ Changed file.device to allow it to skip the first sector of PCTask hard disk files, so you can use FILE0: (xfsd / file.device) on them. Also new DOCS for file.device in the guide (->usage->file.device). Oh yes it also sends back a sensible geometry for .d64 files. This was necessary to implement a C64 disk handler. 1541 disk images may now be accessed via FILE0: (xfsd), but only to display directories at present. You will of course require Catweasel to access the disks directly. This is intended to eventually become a combined 1541/1581 handler (when I get some 1581 info). devd (the DEV: handler) can now accept a third parameter for FLAGS after the unit number (ie DEV:multidisk.device,0,7) to enable you to use it with Catweasel. Oh yes, devd is now mentioned in the guide (->usage->devd). The guide has been improved, mainly the usage section. -------------------------- xfs211b2 ---------------------------- I've completely re-written the sector access / allocation on the Amiga handler, so as to allow you to write to media larger than floppy disks. Unfortunately I haven't had time to test it, so I don't recommend you use it for anything crucial yet, just media you can afford to re-format. Oh, and I found a few things were missing in the directory cacheing (DC) part of the handler, so I've made DC disks read-only for the moment till I sort it out. Also, for some reason the utf-8 internal names were being sent to the Amiga name hashing routines, causing all files whose names contained accented characters to be put on the wrong hash chain. If you have any disks written using this I suggest you use the old version of the handler to copy the files off the disks then use 211b2 or later to write them back (if it works!). No further additions to any other handlers, 'cause I've been adapting various compression routines, to see how easy it would be to add archive-handling to xfsd. I might as well mention that I had hoped to replace the rather awkward DMS uncrunching in file.device, but I couldn't get access to the source on the Aminet. Oh, didn't you know file.device could read DMS files? Well I can't recommend it. Or DMS for that matter. But you will need both, as file.device calls DMS to do the work. -------------- xfs211b (only released on cover cd) -------------- MAC handler does something at last. You can now do directory listings and read the data forks of files. Temporarily disabled ExamineAll support so that ExamineAll should now work properly. Yes you did read that right. If a handler doesn't support ExamineAll the Dos emulates it via Examine and ExamineNext. I'll re-enable it when it's fixed. On the QL, accented characters should now be completely usable in filenames, previously they would only read correctly. Oh, and I've upgraded the x-code utility (to V1.01), and I've replaced the geometry program with a more general device command utility called devio (no docs for it but it's simple to use). Oh, there seems to be some confusion as to the names of the mountlists. I've made sure they're all named in the same way (mount.#?). Finally, I've changed all the flags fields in the mountlists to make all volumes appear on the Workbench. So if you use xfsd at the same time as another handler for the same disk, something strange may happen (unless you edit the flags field to stop xfsd mounting volume entries - see mount.xfsd).