summaryrefslogtreecommitdiff
path: root/gnu/libexec/uucp/uucico
Commit message (Collapse)AuthorAgeFilesLines
* This commit was manufactured by cvs2svn to create tagrelease/2.2.2_cvscvs2svn1997-05-1916-16/+16
| | | | | | | 'RELENG_2_2_2_RELEASE'. This commit was manufactured to restore the state of the 2.2.2-RELEASE image. Releases prior to 5.3-RELEASE are omitting the secure/ and crypto/ subdirs.
* Make cu/uucico sgid dialer to help to work with others lockfiles,Andrey A. Chernov1995-09-141-2/+3
| | | | | | | they can't open root.dialer lockfiles in old variant. Notes: svn path=/head/; revision=10744
* Upgrade 1.06 -> 1.06.1Andrey A. Chernov1995-08-212-8/+13
| | | | Notes: svn path=/head/; revision=10152
* Commit delta: current -> 1.06 + FreeBSD configurationAndrey A. Chernov1995-08-1916-343/+1143
| | | | Notes: svn path=/head/; revision=10110
* Remove trailing whitespace.Rodney W. Grimes1995-05-3010-55/+55
| | | | Notes: svn path=/head/; revision=8858
* configuration files are in /etc/uucp and spool files are in /var/spool/uucpJean-Marc Zucconi1995-05-201-9/+9
| | | | Notes: svn path=/head/; revision=8661
* Install uuconv/uuchk to /usr/sbinAndrey A. Chernov1995-05-131-2/+2
| | | | Notes: svn path=/head/; revision=8492
* From Johannes Stille:David Greenman1994-11-062-24/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When we get an EN8 response while we're already sending the file using the i protocol, this can happen: In send.c, flocal_send_await_reply() is called. This function calls flocal_send_fail() to process the aborted transfer. After this, we run into the branch that calls ffileseekend() to force the end of the actual transfer. Now flocal_send_fail() frees qtrans, but qtrans is still used later! I propose to fix this by moving the usfree_send(qtrans) out of flocal_send_fail(), as in the patch I append to this mail. ... I have found a race condition in the uucp 1.05 code. The typical result is that the connections mysteriously fails with "conversation failed", even while all files were transmitted. This is the problem: At least for the i protocol, the code to send a packet can receive and process packets after sending. In several places in the code, we send a command and then prepare to receive an answer. Now the answer might already arrive during the call that sends the command while we aren't ready to process it. The general solution is IMHO first to do all preparations and only as a last step to send out the command. Reviewed by: John Dyson Submitted by: Johannes Stille Notes: svn path=/head/; revision=4208
* Back out previous change and allow uucico to run by others,Andrey A. Chernov1994-05-311-3/+2
| | | | | | | this required by several programs Notes: svn path=/head/; revision=1659
* I forget to add BINGRP=$(group)Andrey A. Chernov1994-05-311-1/+2
| | | | Notes: svn path=/head/; revision=1655
* Don't allow others run uucicoAndrey A. Chernov1994-05-311-2/+2
| | | | Notes: svn path=/head/; revision=1649
* Fix -z key, patch from TaylorAndrey A. Chernov1994-05-251-21/+20
| | | | Notes: svn path=/head/; revision=1552
* Upgrade to version 1.05Andrey A. Chernov1994-05-0715-536/+1423
| | | | Notes: svn path=/head/; revision=1464
* Fix gross spelling and typographical errors pointed out by Keith Bostic.Jordan K. Hubbard1994-04-241-4/+4
| | | | Notes: svn path=/head/; revision=1411
* Fixed manual page names from .0 to .8.Rodney W. Grimes1993-08-061-2/+2
| | | | Notes: svn path=/head/; revision=249
* Taylor UUCP 1.04J.T. Conklin1993-08-0515-0/+15615
Notes: svn path=/head/; revision=242