🚀 go-pugleaf

 In article <824780394_OASIS_@compuserve.com>
  100710.1360@compuserve.com (Bruno Kozlowski) said:-

>    Is there a list of bugs of the Oasis package, and known cures? It
>would be interesting to make one, helping new users... Or a sort of FAQ.
>
>    I just found one, Oasis corrupts the history file when unbatching...
>exactly not corrupts, but adds double lines, with Message-IDs of unbatched
>articles... but NOS made this history file with the same IDs before. This
>results in a more than twice as long file as it must be, or if you prefer,
>in a 1000 ID list (Oasis cuts the last 1000 when you expire a group), only
>max 500 lines are usable.

This appears to happen in stages. First thing I notice is one or more 
faulty articles. A few unbatches later it will bomb whilst unbatching 
by trying to go back to a group it has just completed. It will 
persistently bomb after that. Re-indexing can help but then all the 
articles are left unread so it is normally easier to expire the lot 
then unbatching works fine.

>    If you poll more than one server, this can result in a certain amount
>of articles downloaded twice, NOS remembering only the last 500... and
>different servers recieving the same article at different dates. With my
>setup I would need +-2000 IDs in history to be sure.

You can also end up severing your newsfeed so that some groups are 
attached to one server and the others to another (nntp.dat).

>    Other bugs?
> - the post percent bug (NOS bug actually)

Either double up % when you type them, use search and replace in a 
text editor or if you are lucky the article can be emailed to news. 
This is a really annoying bug caused by the simple omission of "%s" 
in one line of code. Anybody with Lattice want to recompile the 
source?

> - the post (not on demon) bug (NOS update is the cure)
> - the slow clock corruption (+-2 seconds each time you start the prg)

I've never got any joy out of the time server - I rely on having my 
system clock set slightly behind the real time. History headers then 
stop the duplicates.

> - the loose-last-line in articles bug

Another dead annoying one. Anybody want to write a decent batch.txt 
bodger? I don't think Oasis takes the byte count after rnews into 
account either.

> - the hide-last-line in window bug

Is this the same as the loose-last-line? I haven't the inclination to 
check.

> - the unbatch bombs.

> - no use of the Reply-to: header
> - no use of the "Followup-to: poster" header
> - no use of the "Followup-to:" header at all

A sad omission! -(

> - now this "doubled lines" in history file bug

Looks like I misunderstood you above?

> - the lines more than 255 chars cutted bug

The RFC states 512 chars max. In reality any length line should be 
received but a maximum of 512 sent (including termination chars iirc).

> - the Organi[sz]ation: header bug
> - sometimes a disk-operation while reading messagebase bombs

I can't even begin to guess the cause of this.

> - no cross-posting when replying to a crosspost
> - the yellow-pages cuts too long email addresses

Haven't had this one arise.

> - the edit previously written article bug (edit xx.TXT.TXT)

Use an external editor - it may have something to do with the 
messagebase blank screens and bombs - maybe a dumb strcat() stuffing 
some vital storage?

> - the "501 newsgroup usage" error related bug

Two bugs here - Nos is (obviously) broken but the provider should 
accept the article anyway because the RFC states the last setting 
should remain in effect and as Nos sends the valid group then the duff 
one the provider is at fault. This probably explains why this one 
hasn't cropped up in the past.

>    I think it's all the problems I know of, if you know another one or
>have a cure against one of this bugs...

That's my 2 pence worth anyway :-)

>    By the way, not Oasis but NOS: I dont know why, but absolutly cant
>send (nor recieve) smtp mail... I tried 7845 different startup.noses, and
>have always a bad crash (2 bombs with Falcon locked, reset necessary)
>immediatly when I type "smtp kick" (or wait for autokicks) even if there
>is NO mail to send... the last lines in the NOS.LOG file are "dogateway:
>resolve gateway = 95aed504" and "smtpkick: resolve addr = 0". I'd be
>gratefull if someone could help... actually it's perhaps not the better
>group to ask this, as I'm using the smtp server mail.compuserve.com... and
>the problem might be from there.

Pure guesswork here ...

95aed504 looks like a machine address so maybe it's got into the UDP 
or TCP code and dying there?

Why is it resolving the gateway? Does it have to? The demon gateway is 
specified as an address. Is mail.compuserve.com actually a gateway?

Try circumventing this by sending direct. What does "smtp wait 60" do? 
Does it still crash immediately or does it wait the 60 seconds then 
crash?


__

Guy Harrison

guy@swampdog.demon.co.uk