home *** CD-ROM | disk | FTP | other *** search
- /*
- * Things to be done on the CFS in the future (search for 'ToDo:') :
- *
- * - AmigaDOS 2.0 Devicelist-locking (in createvolnode()) (when
- * documentation becomes avaiable). And everywhere it can replace Forbid().
- * Only on dos.library >= v36, though!
- *
- * - Let DiskState/DiskType reflect state of underlying handler
- * (affects diskinfo() (and volumenode?)).
- *
- * - Test Lock() and Open() mode values, and flag unknown values as
- * invalid ERROR_ACTION_NOT_KNOWN (otherwise future modes might confuse
- * the handler if passed to the ufs).
- *
- * - CFSLockParent() is pretty ugly... I'll have to see what I can do
- * about that.
- *
- * - Library open shouldn't really happen as it does, since it can load
- * from disk, that is use our DOS port. Must let a child process do the
- * OpenLibrary(), perhaps together with the DeviceProc() call.
- * (Actually, under 2.0 the OS takes care of this problem, so probably
- * I shouldn't bother).
- * On a related note, the 'OpenLibrary()' hack in 'xpk.c' to use Xpk in
- * 1.3 is really ugly.
- *
- * - Mounting a CFS unit above a DFx: (or other removable device) is
- * probably counter-intuitive, since it will lock on permanently to the
- * disk in the drive when the handler is loaded (so it won't catch a disk
- * change, but will request 'please insert volume...' instead). I feel
- * this is somehow the most 'pure' way to do things (simply assign the
- * handler to a specific FileLock). However, if I get some requests
- * for it, I will probably include a hack to fix this (perhaps a
- * diskchange interrupt, perhaps a DiskChange-like Shell-command).
- * On second thoughts: Perhaps invoking DeviceProc() to get the root lock
- * on every DEVICE-name reference (= abs. path with zero lock ?).
- * NOTE: This would affect Info(), too (which disk is currently in
- * drive?). And perhaps others?
- *
- * - Remove NUKE and PowerPacker code.
- *
- * - Check out the hook interface to the xpk library when docs become
- * available.
- *
- * - Probably need some error-checking in xFileType().
- *
- * - Need some error checking in IsXpkFile(): failure in attempt to
- * obtain the file size can result in the file position being unknown.
- *
- * - ExNext() on an xpk file does XpkExamine() twice: once to determine
- * that the file is indeed xpk, and once to get the uncompressed size.
- *
- * - Should check for bad eror returns (ie. an UnLock() trashes the
- * error code from a failed call to UFS). And check for ioerr set in CFS.c
- * (and elsewhere?).
- *
- * - Some sensible error reporting in the case of a bad option file.
- *
- * - xGetFileSize() in 'dosfunc.c' should use Examine_FH() if posssible.
- * And xFileSizeXfh should be changed/merged with xGetFileSize.
- *
- * - Something strange's going on in 'xpk.c'/xpkunpackout()/XIO_SEEK.
- * It shouldn't refer the the xFH.
- *
- * - The code for RawCFSOpen() in 'file.c' really needs to be cleaned up.
- *
- * - Check out: What ought to happen with the file handle when a Close()
- * fails?
- *
- * - Some sort of mapping from Xpk error codes to AmigaDOS error messages
- * would be nice.
- *
- * - Option to make XFH only keep xpkmaster.library open when nessesary,
- * thereby making it possible to flush the lib when not used.
- *
- * - Option to prevent XFH from creating a volume node.
- *
- * - Fix bug with deadlock on DeviceProc() by using Randell's trick
- * (and use GetDeviceProc() instead). Also can then call dos.library,
- * making it possible to move the option file initialisation to a very
- * early stage (just Open() the primary option file as soon as its name
- * is available). KS2.0 (or 3.0?) only.
- *
- * - Consider problems regarding the ACTION_DIE packet. Amongst these
- * are issues about code unloading, and left-overs in xfhsemaphore (like
- * the rootlock).
- *
- * - Option to prevent compression of files already compressed with Xpk.
- *
- * - Option to resolve soft-links transparently. Note: the big problem
- * is with softlinks refering to XFH itself - this will probably require a
- * multi-treaded handler. Also, some mechanism to prevent loops is needed.
- *
- *
- * BUG LIST:
- *
- * - Currently (under KS 2.0), the underlying filesys used by CFS must
- * already be loaded when CFS is first referenced - otherwise AmigaDOS will
- * hang. What happens is that CFS tries to fire up a new handler process
- * through DeviceProc. However, at this point, CFS has not yet returned its
- * initial packet (it is, after all, still initialising). The locking
- * mechanish on the DeviceList now ensures that DeviceProc() doesn't return
- * to CFS: until CFS returns its initial packet - which of course it cannot
- * do if it is hanging in DeviceProc().
- *
- * - Silent prayers that the underlying filesys doesn't go away between
- * the call to DeviceProc() (which obtains the procid) and the Lock() call
- * on the root dir of the CFS.
- *
- * - Trying to obtain an exclusive lock on "/" or "...//" will always
- * fail, regardless of whether there is already another reference to the
- * directory (someone let me know if this is a problem).
- *
- * - Messing with the underlying filesystem during CFS operation is a
- * bad idea. For example, during a Lock(...,EXCLUSIVE_LOCK), if the file
- * is changed after the file type (XObj, Xpk etc.) has been changed, but
- * before it is xLock()'ed, CFS won't pick up this change. (A bit
- * technical, yes, but the change of this happening is really, really
- * small. It should be OK to mess with the underlying file system if it
- * doesn't interfere with the files/dirs that CFS is currently working
- * with.
- *
- * - Sigh... another bug in CFSLockParent() etc: For a plain file
- * "foo", Lock("foo//") fails, while Lock("foo/") succeeds...
- *
- * - There may be problems with redirection of requesters since the app
- * is not talking directly to the UFS.
- *
- *
- *
- * OTHER PROBLEMS:
- *
- * - (pre-2.0 compatability) It seems that the arp.library CompareLock()
- * call is broken, in that it assumes the lock->fl_Key field of a filelock
- * uniquely identifies the locked object. This is not the case for the CFS.
- * Use the 2.0 SameLock() call instead.
- * A patch for the arp CompareLock() function is available.
- *
- *
- * POSSIBLE IMPROVEMENTS.
- *
- * - Currently, xFileType does xSeek() a bit more than nessesary.
- *
- *
- */
-