18 Commits

Author SHA1 Message Date
peter
289c0d262f $Id$ -> $FreeBSD$ 1999-08-27 23:37:10 +00:00
peter
6bdaa5c802 Revert $FreeBSD$ to $Id$ 1997-02-22 15:28:58 +00:00
jkh
808a36ef65 Make the long-awaited change from $Id$ to $FreeBSD$
This will make a number of things easier in the future, as well as (finally!)
avoiding the Id-smashing problem which has plagued developers for so long.

Boy, I'm glad we're not using sup anymore.  This update would have been
insane otherwise.
1997-01-14 07:20:47 +00:00
ache
5dadbad941 Make cu/uucico sgid dialer to help to work with others lockfiles,
they can't open root.dialer lockfiles in old variant.
1995-09-14 22:18:39 +00:00
ache
30ce7d007c Upgrade 1.06 -> 1.06.1 1995-08-21 11:28:26 +00:00
ache
b06a057b82 Commit delta: current -> 1.06 + FreeBSD configuration 1995-08-19 21:30:30 +00:00
rgrimes
2ad6f3dee6 Remove trailing whitespace. 1995-05-30 05:05:38 +00:00
jmz
582eb7ce21 configuration files are in /etc/uucp and spool files are in /var/spool/uucp 1995-05-20 21:25:25 +00:00
ache
2177a2ea4f Install uuconv/uuchk to /usr/sbin 1995-05-13 12:30:17 +00:00
dg
a8a06384b5 From Johannes Stille:
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
1994-11-06 10:17:13 +00:00
ache
0f8691556b Back out previous change and allow uucico to run by others,
this required by several programs
1994-05-31 15:55:43 +00:00
ache
7b66d7143b I forget to add BINGRP=$(group) 1994-05-31 05:46:42 +00:00
ache
dd4742288d Don't allow others run uucico 1994-05-31 05:08:11 +00:00
ache
1f8ec9b7f6 Fix -z key, patch from Taylor 1994-05-25 20:14:52 +00:00
ache
e7465d2aba Upgrade to version 1.05 1994-05-07 18:14:43 +00:00
jkh
30d7ba45a9 Fix gross spelling and typographical errors pointed out by Keith Bostic. 1994-04-24 01:22:07 +00:00
rgrimes
bb17304d3a Fixed manual page names from .0 to .8. 1993-08-06 23:38:29 +00:00
conklin
9445dd1201 Taylor UUCP 1.04 1993-08-05 18:28:27 +00:00