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)
Date: 11 Nov 92 15:12:40 GMT
Distribution: usa
Organization: Raven Enterprises -- Piscataway, NJ USA
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