home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / sys / amiga / applicat / 8510 < prev    next >
Encoding:
Internet Message Format  |  1992-11-10  |  3.2 KB
  1. Xref: sparky comp.sys.amiga.applications:8510 alt.sys.amiga.uucp:2661
  2. Newsgroups: comp.sys.amiga.applications,alt.sys.amiga.uucp
  3. Path: sparky!uunet!ukma!darwin.sura.net!mlb.semi.harris.com!su102b!mwills
  4. From: mwills@su102b.ess.harris.com (Scott Wills)
  5. Subject: Re: XPK 2.4 & XFH 1.12
  6. References: <1992Nov9.150411.8348@mlb.semi.harris.com> <Randy_Schnedler.0jc5@fcircus.sat.tx.us>
  7. Date: 10 Nov 92 20:13:45 GMT
  8. Nntp-Posting-Host: su102b.ess.harris.com
  9. Distribution: usa
  10. Reply-To: Scott.Wills@dolphin.ess.harris.com (M. Scott Wills)
  11. Organization: Harris Corporation, Government Aerospace Systems Division.
  12. Sender: news@mlb.semi.harris.com
  13. Message-ID: <mwills.721426425@su102b>
  14. Lines: 49
  15.  
  16. Randy_Schnedler@fcircus.sat.tx.us (Randy Schnedler) writes:
  17.  
  18. >In <1992Nov9.150411.8348@mlb.semi.harris.com>, mwills@su102c.ess.harris.com (Scott Wills) writes:
  19. >> I decided to try XPK/XFH (external compressor
  20. >> protocol/auto-compressing file system handler) to compress my usenet
  21. >> news articles subdirectory (UUNews:) for AmigaUUCP 1.16D and ran into
  22. >> a problem that others may be interested in:
  23.  
  24. >    I _just_ did this today so I'm very interested!  ;-)
  25.  
  26. >> 
  27. >> The articles auto-compress/uncompress fine, but the ".next" file which
  28. >> keeps track of the "next" article number (and file name) was not
  29. >> updated properly.  So every new article was written to the same file,
  30. >> overwriting the previous one.  I remembered reading that not all 2.04
  31. >> file system requests (packets) are implemented by XFH 1.12, including
  32. >> "open for appending".  So I tried manually uncompressing all the
  33. >> ".next" files (one per newsgroup) with hopes that XFH would leave it
  34. >> alone.  It worked!  Now things appear to be working fine.
  35.  
  36. >    Why does XFH leave it alone?  The next time it's written, it
  37. >will be compressed, won't it?
  38.  
  39. Rnews must first read the file to determine the next article number to
  40. use, then increment the value, rewind the file and and write the new
  41. value back to the file.  It could accomplish this via an open(r/w),
  42. read, rewind, write; or via open(r), read, close, open(w), write (I
  43. don't have the source handy).  In either case, XFH has to decide how
  44. to deal with the write to an existing file.  I suspect that the former
  45. case would make it difficult for XFH to compress the (formerly
  46. uncompressed) existing file.  If the latter case were implemented as
  47. "delete" then "create" in the file handler, it might behave as you
  48. suggest.
  49.  
  50. The current behavior is A Good Thing in this case, but if my
  51. interpretation is correct, this behaivor may be overly dependent on
  52. the current implementation of XFH and AmigaUUCP's RNews.  The real
  53. problem is that XFH did not allow RNews to update the .next file when
  54. it WAS compressed (NUKED).
  55.  
  56. Scott
  57. --
  58. ------------------------------------------------------------------------------
  59. M. Scott Wills,  Mail Stop: 102-4844     INTERNET: mwills@su102c.ess.harris.com
  60. Harris Corporation                       UUCP:     uunet!x102a!mwills
  61. Government Aerospace Systems Division    CCMail:   harris.mwills01
  62. P.O. Box 94000                           FAX:       407-729-3211
  63. Melbourne, Florida 32902                 Voice:    407-729-3283
  64. ------------------------------------------------------------------------------
  65.