home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / sys / amiga / applicat / 8701 < prev    next >
Encoding:
Internet Message Format  |  1992-11-16  |  2.0 KB
  1. Path: sparky!uunet!mcsun!sunic!dkuug!diku!bombadil
  2. From: bombadil@diku.dk (Kristian Nielsen)
  3. Newsgroups: comp.sys.amiga.applications
  4. Subject: Re: IS XPK SAFE?
  5. Message-ID: <1992Nov16.123402.1906@odin.diku.dk>
  6. Date: 16 Nov 92 12:34:02 GMT
  7. References: <Bxnwv6.At@javelin.sim.es.com> <1992Nov15.194207.7894@neptune.inf.ethz.ch>
  8. Sender: bombadil@rimfaxe.diku.dk
  9. Organization: Department of Computer Science, U of Copenhagen
  10. Lines: 35
  11.  
  12. umueller@iiic.ethz.ch (Urban Dominik Mueller) writes:
  13.  
  14. >In article <Bxnwv6.At@javelin.sim.es.com> dingebre@imp.sim.es.com (David Ingebretsen) writes:
  15.  
  16. >>I'm very impressed with the XPK package and the XFH and XPK-handler
  17. >>file systems. BUT how reliable are they?
  18.  
  19. As the author of XFH, I can say that a primary design goal was safety.
  20. This means stable operation (ie. lots of redundant error checking on
  21. parameter values etc.) as well as data security. One example is the way
  22. autocompression is handled: First write the file normally, then compress
  23. to another file, then rename both files, and only if the compressed file
  24. is fully safe delete the original. So even a complete system crash
  25. leaves you with a good chance of saving the data. The price is with
  26. efficiency; XFH is by no means optimal with respect to speed or memory
  27. usage.
  28.  
  29. Needless to say, even though I spend much efford keeping the source
  30. 'clean', there can still be bugs (like the filenote/Examine() one
  31. described below). And the compression libraries could have problem as
  32. well.
  33.  
  34. >>4. Which handler would you recommend?
  35.  
  36. >Both have their drawbacks. Xpk-Handler is new to this release and thus pretty
  37. >untested. XFH has a bug that can cause crashes when ExAll() is used on it
  38.  
  39. I would like to clarify this. The problem is with ExNext() (ExAll()
  40. isn't supported but is emulated by dos.library), so every dir-listing
  41. program will experience it. If ExNext() is performed on a file with a
  42. filenote starting with a character with code greater than about 80, XFH
  43. can trash memory. A fix has been made, but I've not had the time to
  44. release it yet.
  45.  
  46.     - Kristian (author of XFH).
  47.