sentinel@killer.UUCP (The Sentinel) (01/28/88)
I'm having a bit of a problem with UUPC for the Amiga. I am using the
binaries from Fish disk #109. I am attempting to use UUPC to transfer mail
between myself and a Sys V system (the one from which I am posting this,
as a matter of fact). It works fine for mail from my Amiga to the host, but
not the other way around.
What happens is this: UUPC calls, logs in, and delivers mail just like
it's supposed to. Then it receives all of the D. and X. files for the mail
coming from the host, and logs off. So far, so good. At this point, UUPC
is supposed to scan the :usr/spool/uucp directory for incoming X. files,
and execute the commands found in them. However, it does not do this, so
my mail just sits around in the spool directory instead of being moved to
my mailbox.
Running UUPC with a high debugging level provides some interesting
information on this... apparently, UUPC goes through the directory but
never properly finds the X. files. The debugging output from the routine
that scans the directory shows that it is comparing filenames to find those
beginning with X., yet it goes right by every one that matches.
I'm not sure whether this is a problem in the program, or just an
oversight on my part. I would like to hear from other users of UUPC...
if you are successfully using this program, please send me some mail
with any information you think might be helpful... problems you've had,
how you've got it set up, etc.
Thanks...
G'day, eh?
--TS
--
Rob Tillotson ...ihnp4!killer!sentinel
320 Brown St. #406 -or-
West Lafayette, IN 47906 dab@s.cc.purdue.edu
(317) 743-8421cmcmanis%pepper@Sun.COM (Chuck McManis) (01/29/88)
In article <3133@killer.UUCP> sentinel@killer.UUCP (The Sentinel) writes:
!> Running UUPC with a high debugging level provides some interesting
!>information on this... apparently, UUPC goes through the directory but
!>never properly finds the X. files. The debugging output from the routine
!>that scans the directory shows that it is comparing filenames to find those
!>beginning with X., yet it goes right by every one that matches.
Could it be that the SysV system is putting something strange in bit 7 of
the characters? Can AmigaDOS find the files if you type dir T#? on the
spool directory? That is about all I can think of that would cause that
behaviour.
--Chuck McManis
uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com
These opinions are my own and no one elses, but you knew that didn't you.arnie@tikal.Teltone.COM (Arnold Koster) (01/30/88)
In article <40372@sun.uucp> cmcmanis@sun.UUCP (Chuck McManis) writes: >In article <3133@killer.UUCP> sentinel@killer.UUCP (The Sentinel) writes: >!> Running UUPC with a high debugging level provides some interesting >!>information on this... apparently, UUPC goes through the directory but >!>never properly finds the X. files. The debugging output from the routine The directory scanning routine in UUPC is case sensitive. When scanning for X. files you will notice that the directory has them identified as x. not X. . A simple temporary fix is to change the template found in one of the header files (I don't have the sources here at work) from an uppercase X to a lower case. The real fix is to rewrite the scanning routine to be insensitive to case. While I'm writing this here are a few more comments about UUPC. It works well once you get past a few problems like the above. If you are lucky enough to get a local site to geve you a newsfeed be aware that UUPC will not handle compressed files. You must either receive the raw files or compress them and run them through btoa. I have a version of btoa that works on the amiga and the compress from one of the fish disks works fine. I have yet to get my unbatch program to work (It GURU's after unbatching the second file) but should have it "RSN" (Mid feb. there's a business trip to France in the way :-) ). When I get it all packaged up I'll make it available thru the net. Next we need a good News reader , anyone game? I'm only a guest for reading news please reply to: --- Ken Koster (N7IPB) algedi!kenk@pilchuck.Data-IO.COM or 12653 NE 95th ...uunet!pilchuck!algedi!kenk or Kirkland,Wa 98033 ...uw-beaver!tikal!pilchuck!algedi!kenk Mine all Mine. Hee Hee :-) :-) Amiga,1.5meg,40megHD,UUPC partial NEWS
cks@radio.toronto.edu (Chris Siebenmann) (01/31/88)
In article <3133@killer.UUCP> sentinel@killer.UUCP (The Sentinel) writes: > > I'm having a bit of a problem with UUPC for the Amiga. I am using the >binaries from Fish disk #109. Binaries built from the sources posted to comp.sources.misc (which is probably what is on Fish disk #109) have quite a few serious bugs. Mail is normally fine if you're only talking to a single system; but add another system, or try to send binary files, and you'll have troubles. > What happens is this: UUPC calls, logs in, and delivers mail just like >it's supposed to. Then it receives all of the D. and X. files for the mail >coming from the host, and logs off. So far, so good. At this point, UUPC >is supposed to scan the :usr/spool/uucp directory for incoming X. files, >and execute the commands found in them. However, it does not do this, so >my mail just sits around in the spool directory instead of being moved to >my mailbox. > Running UUPC with a high debugging level provides some interesting >information on this... apparently, UUPC goes through the directory but >never properly finds the X. files. The debugging output from the routine >that scans the directory shows that it is comparing filenames to find those >beginning with X., yet it goes right by every one that matches. I've run into a problem that may be related this (and might even be this problem; I can't quite tell from your description). I recently started connecting to a SysV machine from Prime. Mail to it works fine, but mail from it winds up with a X. file called X.ziebmefXXXX (ziebmef is my Amiga) instead of a file called X.bramboXXXX (brambo is the other system), which is what uupc is looking for. I'm not sure why this is happening; other versions of uucp (Sun 3.4 and 3B1 SysV) seem to work fine and wind up with the correct X. name. Nor do I know how to fix the problem. Renaming the X. file to what uupc was looking for worked fine, but I don't want to have to do this for every bit of mail. -- "I shall clasp my hands together and bow to the corners of the world." Number Ten Ox, "Bridge of Birds" Chris Siebenmann {allegra,mnetor,decvax,pyramid}!utgpu!radio!cks cks@radio.toronto.edu or ...!utgpu!{chp!hak!ziebmef,ontmoh}!cks
hamilton@uxc.cso.uiuc.edu (01/31/88)
ken koster says: > be aware that UUPC will not handle compressed files. > You must either receive the raw files or compress them and run > them through btoa. i've been working on uupc on the ibm pc for my employer; eventually i'll port my mods to my amiga also. in the meantime, i think i fixed the problem with binary files by replacing a couple strncpy()s with movmem()s in dcpgpkt.c or dcpxfer.c. the strncpy()s were used to move data between a packet buffer and an i/o buffer; since strncpy() will stop as soon as it sees a '\0', this was disastrous for binary data. wayne hamilton U of Il and US Army Corps of Engineers CERL UUCP: {ihnp4,seismo,pur-ee,convex}!uiucuxc!hamilton ARPA: hamilton@uxc.cso.uiuc.edu USMail: Box 476, Urbana, IL 61801 CSNET: hamilton%uxc@uiuc.csnet Phone: (217)333-8703 CIS: [73047,544] PLink: w hamilton