Commit Graph

18 Commits

Author SHA1 Message Date
Peter Wemm
9b7a44a60e $Id$ -> $FreeBSD$ 1999-08-27 23:37:10 +00:00
Peter Wemm
2f4706e95c Revert $FreeBSD$ to $Id$ 1997-02-22 15:28:58 +00:00
Jordan K. Hubbard
1130b656e5 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
Andrey A. Chernov
f73f49f214 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
Andrey A. Chernov
2ac29091ed Upgrade 1.06 -> 1.06.1 1995-08-21 11:28:26 +00:00
Andrey A. Chernov
6ec4b3339b Commit delta: current -> 1.06 + FreeBSD configuration 1995-08-19 21:30:30 +00:00
Rodney W. Grimes
4399be3cbd Remove trailing whitespace. 1995-05-30 05:05:38 +00:00
Jean-Marc Zucconi
f7fda1a3c9 configuration files are in /etc/uucp and spool files are in /var/spool/uucp 1995-05-20 21:25:25 +00:00
Andrey A. Chernov
12421b942f Install uuconv/uuchk to /usr/sbin 1995-05-13 12:30:17 +00:00
David Greenman
1e8ee278b6 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
Andrey A. Chernov
4a62bda2ae Back out previous change and allow uucico to run by others,
this required by several programs
1994-05-31 15:55:43 +00:00
Andrey A. Chernov
33dddc66c6 I forget to add BINGRP=$(group) 1994-05-31 05:46:42 +00:00
Andrey A. Chernov
5789078704 Don't allow others run uucico 1994-05-31 05:08:11 +00:00
Andrey A. Chernov
40a845cd5b Fix -z key, patch from Taylor 1994-05-25 20:14:52 +00:00
Andrey A. Chernov
8d29233fea Upgrade to version 1.05 1994-05-07 18:14:43 +00:00
Jordan K. Hubbard
2caac73e76 Fix gross spelling and typographical errors pointed out by Keith Bostic. 1994-04-24 01:22:07 +00:00
Rodney W. Grimes
f1d678eac9 Fixed manual page names from .0 to .8. 1993-08-06 23:38:29 +00:00
J.T. Conklin
a5ebd84e62 Taylor UUCP 1.04 1993-08-05 18:28:27 +00:00