home *** CD-ROM | disk | FTP | other *** search
- Xref: sparky comp.sys.amiga.applications:8536 alt.sys.amiga.uucp:2663
- Path: sparky!uunet!pmafire!news.dell.com!natinst.com!cs.utexas.edu!zaphod.mps.ohio-state.edu!saimiri.primate.wisc.edu!ames!agate!stanford.edu!rutgers!bobsbox.rent.com!bobl
- From: bobl@bobsbox.rent.com (Bob Lindabury - SysAdmin)
- Newsgroups: comp.sys.amiga.applications,alt.sys.amiga.uucp
- Subject: Re: XPK 2.4 & XFH 1.12 (AmigaUUCP)
- Message-ID: <bobl.99dq@bobsbox.rent.com>
- Date: 11 Nov 92 15:12:40 GMT
- References: <1992Nov9.150411.8348@mlb.semi.harris.com> <Randy_Schnedler.0jc5@fcircus.sat.tx.us> <mwills.721426425@su102b>
- Distribution: usa
- Organization: Raven Enterprises -- Piscataway, NJ USA
- Lines: 61
- X-NewsSoftware: GRn 1.16f (10.17.92) by Mike Schwartz & Michael B. Smith
-
- In article <mwills.721426425@su102b> mwills@su102b.ess.harris.com (Scott Wills) writes:
- > Randy_Schnedler@fcircus.sat.tx.us (Randy Schnedler) writes:
- >
- > >In <1992Nov9.150411.8348@mlb.semi.harris.com>, mwills@su102c.ess.harris.com (Scott Wills) writes:
- > >> I decided to try XPK/XFH (external compressor
- > >> protocol/auto-compressing file system handler) to compress my usenet
- > >> news articles subdirectory (UUNews:) for AmigaUUCP 1.16D and ran into
- > >> a problem that others may be interested in:
- >
- > > I _just_ did this today so I'm very interested! ;-)
- >
- > >>
- > >> The articles auto-compress/uncompress fine, but the ".next" file which
- > >> keeps track of the "next" article number (and file name) was not
- > >> updated properly. So every new article was written to the same file,
- > >> overwriting the previous one. I remembered reading that not all 2.04
- > >> file system requests (packets) are implemented by XFH 1.12, including
- > >> "open for appending". So I tried manually uncompressing all the
- > >> ".next" files (one per newsgroup) with hopes that XFH would leave it
- > >> alone. It worked! Now things appear to be working fine.
- >
- > > Why does XFH leave it alone? The next time it's written, it
- > >will be compressed, won't it?
- >
- > Rnews must first read the file to determine the next article number to
- > use, then increment the value, rewind the file and and write the new
- > value back to the file. It could accomplish this via an open(r/w),
- > read, rewind, write; or via open(r), read, close, open(w), write (I
- > don't have the source handy). In either case, XFH has to decide how
- > to deal with the write to an existing file. I suspect that the former
- > case would make it difficult for XFH to compress the (formerly
- > uncompressed) existing file. If the latter case were implemented as
- > "delete" then "create" in the file handler, it might behave as you
- > suggest.
- >
- > The current behavior is A Good Thing in this case, but if my
- > interpretation is correct, this behaivor may be overly dependent on
- > the current implementation of XFH and AmigaUUCP's RNews. The real
- > problem is that XFH did not allow RNews to update the .next file when
- > it WAS compressed (NUKED).
- >
- > Scott
- > --
- > ------------------------------------------------------------------------------
- > M. Scott Wills, Mail Stop: 102-4844 INTERNET: mwills@su102c.ess.harris.com
- > Harris Corporation UUCP: uunet!x102a!mwills
- > Government Aerospace Systems Division CCMail: harris.mwills01
- > P.O. Box 94000 FAX: 407-729-3211
- > Melbourne, Florida 32902 Voice: 407-729-3283
- > ------------------------------------------------------------------------------
-
- I would suggest using CNews as it doesn't require the reading updating
- or writing of .next files. I don't know w
-
- --
- Bob Lindabury
-
- InterNet: bobl@bobsbox.rent.com | Raven Enterprises
- UUCP: ...rutgers!bobsbox!bobl | 25 Raven Avenue
- BitNet: bobl%bobsbox.rent.com@pucc | Piscataway, NJ 08854
- Home #: +1 908/560-7353 | +1 908/271-8878
-