default, at least in BSD. This used to be automatic, because chown(2)
didn't follow symlinks. When chown(2) was changed to follow symlinks
in BSD4.4, chown(8) was changed to not follow symlinks by default.
The previous commit broke this. The first victim was bsd.prog.mk,
which uses a plain chown in an attempt to change the ownership of the
symlinks to `dm' in /usr/games. This fails when it is done before
dm is installed, or messes up the ownership of dm if dm is installed.
Unfixed problems:
1. When lchown(2) was implemented, chown(8) wasn't changed to implement
the historical behaviour of changing ownership of symlinks. I'm not
sure if it should have been. The -HLP options give more complete
control, but they unfortunately don't apply unless the -R option is
specified (a problem shared with other commands, e.g., cp; I guess
we're supposed to use -R even for non-recursive traversals).
2. If we implement the historical behaviour, then -h would become a no-op
and should be left undocumented.
3. The man page suggests that without option -h, all symlinks (to files
specified in the command line?) are followed. It's not clear what
"the file" is. These bugs were introduced when -h was documented.
4. The correct interaction of -h with the other flags is not clear.
used. ${LIBFL} is set to a weird value in an attempt to inhibit
its use, but only breaks properly in some contexts.
Fixed the usual style bugs for DPADD and LDADD (disorder, and += for the
initial assignment).
It is important that we keep the ability to send packets to a remote
server and that the packets come from our well-known port, also in
that case.
Reviewed by: peter, rgrimes.
change it w/out informing the program. Instead, use the (now available)
previous state returned by the kernel to make intelligent card
removal/insertion decisions.
is reason enough to make the compilation & installation of sendmail an
make.conf option. I know that you hate negative options Bruce.
PR: 6284
Reviewed by: phk
Submitted by: Adrian Colley <aecolley@world.std.com>
Explanation of the bug: when processing its first request, rarpd
opens a routing socket to send requests to the arp table. It keeps
that socket open afterwards, while waiting for new RARP requests.
Meanwhile, the data received on the routing socket fill up until
they are about 8Kbytes in size. Any additional data is lost.
When rarpd receives its next RARP request, it tries to access the
ARP table via a routing socket call, then waits for the answer to
its own request. This answer is lost because the received data is
already filled: when looking for the reply, rarpd receives only
8kbytes worth of data, then loops waiting forever.
Someone please test it on -STABLE and commit it. We can close the PR
when testing on STABLE is done.
PR: bin/5669
Submitted by: Pierre Beyssac <pb@fasterix.freenix.org>
