Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!linus!philabs!prls!pyramid!decwrl!sun!chuq From: chuq@sun.uucp (Chuq Von Rospach) Newsgroups: net.sources.mac,net.micro.mac,net.news Subject: net.sources.mac problems found Message-ID: <3868@sun.uucp> Date: Mon, 2-Jun-86 16:16:13 EDT Article-I.D.: sun.3868 Posted: Mon Jun 2 16:16:13 1986 Date-Received: Wed, 4-Jun-86 06:46:57 EDT Distribution: net Organization: Fictional Reality, uLtd Lines: 70 Xref: linus net.sources.mac:1134 net.micro.mac:6160 net.news:4100 Last week I posted a note warning of possible problems with the network screwing up files posted to net.sources.mac. Thanks to the large number of people who took the time to answer my questions (72 and counting!) I think I've been able to track down the problems. First of all, it quickly became obvious that the vast majority of the net DID get the posting correctly in comparison to the group that was having problems. So, as far as the net in general is concerned, I don't think there is a problem -- most of the net gets most of the postings correctly most of the time, so mostly there isn't any trouble. Two definite glitches did show up, however: o Pilot Error: In large files split up over multiple postings, it is rather easy to accidently delete an extra line, put things together in the wrong order and generally get things mucked up so they won't work. Solutions: (1) BE CAREFUL. If something doesn't work, go back to your news reader, save all the files over again (better yet, keep copies of all the original stuff) and try once more. It is quite likely that the files are right and that you are wrong, and that you just didn't catch it. On a longer term, I think someone (I don't have the time, unfortunately) should look at some way to automate this process. Something like shar that split things up and figure out how to put them all back together again without a lot of manual cut and paste. I also suggest this program pass along some kind of checksumming (the unix 'sum' command would work fine) for each piece and for the file as a whole so you can tell before downloading or using xbin whether the file has been zapped in transit. o Xbin is buggy!: Almost all of the problems we saw with Boston II was with xbin! Some people were able to get it through xbin, most were not. Many people who could not get xbin to tear apart the file were able to download it and use BinHex just fine. I vaguely remember that someone found and fixed a bug in xbin a while back -- I bet we're running into old versions of that program again. I suggest heavily that someone with a good version of xbin (i.e. one that worked on Boston, or one from someone who remembers what the bug was and knows that the thing is fixed) please clue us in and post a good version of the program. If you have been having problems with bad files from n.s.m, try downloading and using BinHex instead; I bet many of your problems go away. (Just as an editorial comment, I'm never used xbin because I like the idea of using the BinHex checksumming to verify the download. the difference between the BinHex file and the size of the component files just isn't that great, and the extra measure of safety makes me feel a LOT better. Would YOU like some line noise that got through Xmodem to sit in your binary file, just waiting to be executed?) As it stands, I don't think we have much of a problem, fortunately. the net works better than we thought! People posting things should be careful to iinclude clear instructions for rebuilding files, and people trying to download should be careful to follow them. if we do that, and get rid of xbin, a lot of the problems we've seen should go away. chuq chuq -- :From the lofty realms of Castle Plaid: Chuq Von Rospach chuq%plaid@sun.COM FidoNet: 125/84 CompuServe: 73317,635 {decwrl,decvax,hplabs,ihnp4,pyramid,seismo,ucbvax}!sun!plaid!chuq The first rule of magic is simple. Don't waste your time waving your hands and hoping when a rock or a club will do -- McCloctnik the Lucid