home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / sys / amiga / applicat / 8667 < prev    next >
Encoding:
Text File  |  1992-11-15  |  2.8 KB  |  65 lines
  1. Newsgroups: comp.sys.amiga.applications
  2. Path: sparky!uunet!europa.asd.contel.com!darwin.sura.net!paladin.american.edu!news.univie.ac.at!chx400!bernina!neptune!umueller
  3. From: umueller@iiic.ethz.ch (Urban Dominik Mueller)
  4. Subject: Re: IS XPK SAFE?
  5. Message-ID: <1992Nov15.194207.7894@neptune.inf.ethz.ch>
  6. Sender: news@neptune.inf.ethz.ch (Mr News)
  7. Nntp-Posting-Host: c11
  8. Organization: Swiss Federal Institute of Technology (ETH), Zurich
  9. References: <Bxnwv6.At@javelin.sim.es.com>
  10. Date: Sun, 15 Nov 1992 19:42:07 GMT
  11. Lines: 52
  12.  
  13. Author speaking... It is very valid to ask for XPK's safety. Genreally, XPK
  14. seems stable; but I'd never compress anything that you cannot replace or
  15. absolutely need. On the other hand, things like your private module collection
  16. seem a to be a good candidate for compression.
  17.  
  18. In article <Bxnwv6.At@javelin.sim.es.com> dingebre@imp.sim.es.com (David Ingebretsen) writes:
  19. >
  20. >I'm very impressed with the XPK package and the XFH and XPK-handler
  21. >file systems. BUT how reliable are they?
  22. >
  23. >If you use/have used either of these, I would appreciate you thoughts.
  24. >
  25. >1. Have you ever lost data?
  26.  
  27. No reports of data loss because of XPK bugs have reached me so far. In
  28. case it happens to anyone out there, please report immediately as to
  29. save others from suffering the same problem. Of course there are imminent
  30. problems with storing files in packed format: A single corrupted bit
  31. will usually trash the whole files.
  32. Also, you'll have to differ between the packers. NUKE and BLZW are the
  33. oldest ones and can be considered pretty safe. I do test new packers
  34. before adding them to the release archive, but only practice shows 
  35. if they really work 100% flawlessly.
  36.  
  37. >2. Was it obnoxious in any way?
  38.  
  39. Sorry, my English isn't good enough for that one :)
  40.  
  41. >3. Would you do it differently if given another chance?
  42.  
  43. I guess I'm not the one to answer this...
  44.  
  45. >4. Which handler would you recommend?
  46.  
  47. Both have their drawbacks. Xpk-Handler is new to this release and thus pretty
  48. untested. XFH has a bug that can cause crashes when ExAll() is used on it
  49. (like MagicFileRequester does). Neither of them can open files in 
  50. MODE_READWRITE as used when updating files. In general, I would use the
  51. handlers on partitions/directories that are written to only infrequently,
  52. and never for places where your own work (pictures, texts, sources) are
  53. stored.
  54.  
  55. >5. Do you back up your data in the compressed format?
  56.  
  57. If you mean backuping the underlying DH3: instead of XFH:, then certainly.
  58. If you mean compressing before backuping, there's only one program that
  59. does it so far: KwikBackup. I would probably use compression if the backup
  60. drive is slow and the CPU is fast. Good backup programs should offer a
  61. verify mode in that re-reads and re-decompresses, and they should work
  62. with independent chunks so a read error doesn't trash the whole disk.
  63.  
  64.  
  65.