Xref: utzoo news.admin:14481 comp.mail.uucp:6575 Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!zaphod.mps.ohio-state.edu!mips!atha!aupair.cs.athabascau.ca!lyndon From: lyndon@cs.athabascau.ca (Lyndon Nerenberg) Newsgroups: news.admin,comp.mail.uucp Subject: Re: BITFTP Message-ID: Date: 19 May 91 22:57:49 GMT References: Followup-To: news.admin Organization: Athabasca University Lines: 47 stanley@phoenix.com (John Stanley) writes: >gws@xenitec.on.ca (Geoff Scully) writes: >> Can and will are different things. Fixing uucico (umpteen different >> versions from umpteen different vendors) > Lsuc runs umpteen different versions? > Fixing YOUR copy of uucico WILL fix your problem. Adding a disk will >NOT fix the problem, it just puts it off for a while. [ Lots 'o drivel deleted ] > A useful statement. Mail will never fill my spool unless mail fills >my spool. If you had a uucico that would stop accepting things when the >spool got close to full, you could THEN say that human generated mail >will NEVER fill your spool, without any qualifications. John, what version of UUCP do you run? It's obviously very different from the version the rest of us run. Please tell me, in detail, how the uucico at your end knows whether or not it has enough room for an incoming file. Describe the protocol negotiations that take place between the two systems to pass such information as the size of the file about to be transferred, and the amount of space available at the receiving end. What was the name of that protocol? It sure as hell wasn't g, or f, or t, or x, or e. Most versions of uucico will refuse an incoming transfer if the amount of space (or the number of free inodes) in the uucp spool directory's filesystem is below a certain threshold (said threshold being compiled in to uucico). That's it. What is so magic about your version of uucico that it doesn't have this behaviour? And why don't you share the code with us? It would be a Good Thing to have a uucp protocol that would pass along things like the size of the file it's about to send. This would allow the receiver to determine if it can infact receive the entire file without running out of resources. Of course it wouldn't be foolproof, since you can have more than one uucico going at a time, and all of them could be receiving 9 MB files into a partition with 15 MB of free space. Of course, this new protocol will only work if both ends speak it. Since none of the machines lsuc talks to (well, maybe there is one) run the same system, you are suddenly faced with the prospect of porting to other architectures. You're argument that fixing uucico on lsuc will solve the worlds problems is utter nonsense. -- Lyndon Nerenberg VE6BBM / Computing Services / Athabasca University atha!cs.athabascau.ca!lyndon || lyndon@cs.athabascau.ca Packet: ve6bbm@ve6mc.ab.can.noam The only thing open about OSF is their mouth. --Chuck Musciano