home *** CD-ROM | disk | FTP | other *** search
/ Amiga Elysian Archive / AmigaElysianArchive.iso / compress / xfh132.lzh / XFH / src / ToDo < prev    next >
Text File  |  1993-01-19  |  6KB  |  145 lines
  1. /*
  2.  * Things to be done on the CFS in the future (search for 'ToDo:') :
  3.  *
  4.  *  - AmigaDOS 2.0 Devicelist-locking (in createvolnode()) (when 
  5.  * documentation becomes avaiable). And everywhere it can replace Forbid().
  6.  * Only on dos.library >= v36, though!
  7.  *
  8.  *  - Let DiskState/DiskType reflect state of underlying handler
  9.  * (affects diskinfo() (and volumenode?)).
  10.  *
  11.  *  - Test Lock() and Open() mode values, and flag unknown values as
  12.  * invalid ERROR_ACTION_NOT_KNOWN (otherwise future modes might confuse
  13.  * the handler if passed to the ufs).
  14.  *
  15.  *  - CFSLockParent() is pretty ugly... I'll have to see what I can do
  16.  * about that.
  17.  *
  18.  *  - Library open shouldn't really happen as it does, since it can load
  19.  * from disk, that is use our DOS port. Must let a child process do the
  20.  * OpenLibrary(), perhaps together with the DeviceProc() call.
  21.  * (Actually, under 2.0 the OS takes care of this problem, so probably
  22.  * I shouldn't bother).
  23.  *    On a related note, the 'OpenLibrary()' hack in 'xpk.c' to use Xpk in
  24.  * 1.3 is really ugly.
  25.  *
  26.  *  - Mounting a CFS unit above a DFx: (or other removable device) is
  27.  * probably counter-intuitive, since it will lock on permanently to the
  28.  * disk in the drive when the handler is loaded (so it won't catch a disk
  29.  * change, but will request 'please insert volume...' instead). I feel
  30.  * this is somehow the most 'pure' way to do things (simply assign the
  31.  * handler to a specific FileLock). However, if I get some requests
  32.  * for it, I will probably include a hack to fix this (perhaps a
  33.  * diskchange interrupt, perhaps a DiskChange-like Shell-command).
  34.  * On second thoughts: Perhaps invoking DeviceProc() to get the root lock
  35.  * on every DEVICE-name reference (= abs. path with zero lock ?).
  36.  * NOTE: This would affect Info(), too (which disk is currently in
  37.  * drive?). And perhaps others?
  38.  *
  39.  *  - Remove NUKE and PowerPacker code.
  40.  *
  41.  *  - Check out the hook interface to the xpk library when docs become
  42.  * available.
  43.  *
  44.  *  - Probably need some error-checking in xFileType().
  45.  *
  46.  *  - Need some error checking in IsXpkFile(): failure in attempt to
  47.  * obtain the file size can result in the file position being unknown.
  48.  *
  49.  *  - ExNext() on an xpk file does XpkExamine() twice: once to determine
  50.  * that the file is indeed xpk, and once to get the uncompressed size.
  51.  *
  52.  *  - Should check for bad eror returns (ie. an UnLock() trashes the
  53.  * error code from a failed call to UFS). And check for ioerr set in CFS.c
  54.  * (and elsewhere?).
  55.  *
  56.  *  - Some sensible error reporting in the case of a bad option file.
  57.  *
  58.  *  - xGetFileSize() in 'dosfunc.c' should use Examine_FH() if posssible.
  59.  * And xFileSizeXfh should be changed/merged with xGetFileSize.
  60.  *
  61.  *  - Something strange's going on in 'xpk.c'/xpkunpackout()/XIO_SEEK.
  62.  * It shouldn't refer the the xFH.
  63.  *
  64.  *  - The code for RawCFSOpen() in 'file.c' really needs to be cleaned up.
  65.  *
  66.  *  - Check out: What ought to happen with the file handle when a Close()
  67.  * fails?
  68.  *
  69.  *  - Some sort of mapping from Xpk error codes to AmigaDOS error messages
  70.  * would be nice.
  71.  *
  72.  *  - Option to make XFH only keep xpkmaster.library open when nessesary,
  73.  * thereby making it possible to flush the lib when not used.
  74.  *
  75.  *  - Option to prevent XFH from creating a volume node.
  76.  *
  77.  *  - Fix bug with deadlock on DeviceProc() by using Randell's trick
  78.  * (and use GetDeviceProc() instead). Also can then call dos.library,
  79.  * making it possible to move the option file initialisation to a very
  80.  * early stage (just Open() the primary option file as soon as its name
  81.  * is available). KS2.0 (or 3.0?) only.
  82.  *
  83.  *  - Consider problems regarding the ACTION_DIE packet. Amongst these
  84.  * are issues about code unloading, and left-overs in xfhsemaphore (like
  85.  * the rootlock).
  86.  *
  87.  *  - Option to prevent compression of files already compressed with Xpk.
  88.  *
  89.  *  - Option to resolve soft-links transparently. Note: the big problem
  90.  * is with softlinks refering to XFH itself - this will probably require a
  91.  * multi-treaded handler. Also, some mechanism to prevent loops is needed.
  92.  *
  93.  *
  94.  * BUG LIST:
  95.  *
  96.  *  - Currently (under KS 2.0), the underlying filesys used by CFS must
  97.  * already be loaded when CFS is first referenced - otherwise AmigaDOS will
  98.  * hang. What happens is that CFS tries to fire up a new handler process
  99.  * through DeviceProc. However, at this point, CFS has not yet returned its
  100.  * initial packet (it is, after all, still initialising). The locking
  101.  * mechanish on the DeviceList now ensures that DeviceProc() doesn't return
  102.  * to CFS: until CFS returns its initial packet - which of course it cannot
  103.  * do if it is hanging in DeviceProc().
  104.  *
  105.  *  - Silent prayers that the underlying filesys doesn't go away between
  106.  * the call to DeviceProc() (which obtains the procid) and the Lock() call
  107.  * on the root dir of the CFS.
  108.  *
  109.  *  - Trying to obtain an exclusive lock on "/" or "...//" will always
  110.  * fail, regardless of whether there is already another reference to the
  111.  * directory (someone let me know if this is a problem).
  112.  *
  113.  *  - Messing with the underlying filesystem during CFS operation is a
  114.  * bad idea. For example, during a Lock(...,EXCLUSIVE_LOCK), if the file
  115.  * is changed after the file type (XObj, Xpk etc.) has been changed, but
  116.  * before it is xLock()'ed, CFS won't pick up this change. (A bit
  117.  * technical, yes, but the change of this happening is really, really
  118.  * small. It should be OK to mess with the underlying file system if it
  119.  * doesn't interfere with the files/dirs that CFS is currently working
  120.  * with.
  121.  *
  122.  *  - Sigh... another bug in CFSLockParent() etc: For a plain file
  123.  * "foo", Lock("foo//") fails, while Lock("foo/") succeeds...
  124.  *
  125.  *  - There may be problems with redirection of requesters since the app
  126.  * is not talking directly to the UFS.
  127.  *
  128.  *
  129.  *
  130.  * OTHER PROBLEMS:
  131.  *
  132.  *  - (pre-2.0 compatability) It seems that the arp.library CompareLock()
  133.  * call is broken, in that it assumes the lock->fl_Key field of a filelock
  134.  * uniquely identifies the locked object. This is not the case for the CFS.
  135.  * Use the 2.0 SameLock() call instead.
  136.  *    A patch for the arp CompareLock() function is available.
  137.  *
  138.  *
  139.  * POSSIBLE IMPROVEMENTS.
  140.  *
  141.  *  - Currently, xFileType does xSeek() a bit more than nessesary.
  142.  *
  143.  *
  144.  */
  145.