claims multiple times to have failed. The problem is a off_t is
converted into a int and checked for a negative. A true lseek check
should be checking if the off_t is equal to -1 for failure.
(Suggested fix from PR #bin/461)
Submitted by: mark tinguely <tinguely@opus.cs.ndsu.NoDak.edu>
Note that the two "touch"s I took out from do-patch shouldn't have
been there in the first place.
This target may give incorrent results if two separate patches deal
with the same file, and their hunks overlap. (But having those kinds
of patches are bad, and they should be merged anyway.)
Reviewed by: hsu
now safely add a line like
ldconfig -m ${PREFIX}/lib
in ports' Makefiles and packing lists without throwing away some
directories the user may have added.
Submitted by: Mostly by Paul Kranenburg <pk@cs.few.eur.nl>
restricted. Am I the only one who sees the absurdity of having chfn be
a link to chpass, and then denying users permission to use chpass to
change their full names?
Of course, chpass has a much more severe bug in it, which is that it
allows users to change their password database info without first
asking them for their password. I hope to fix this at some point
so that I can merge ypchpass, ypchfn, ypchsh and chpass into one
program (password authentication is required for changing NIS data).
'cycle in netgroup check too greedy').
PR #508 is apparently due to an inconsistency in the way the 4.4BSD
netgroup code deals with bad netgroups. When 4.4BSD code encounters
a badly formed netgroup entry (e.g. (somehost,-somedomain), which,
because of the missing comma between the '-' and 'somedomain,' has
only 2 fields instead of 3), it generates an error message and
then bails out without doing any more processing on the netgroup
containing the bad entry. Conversely, every other *NIX in the world
that usees netgroups just tries to parse the entry as best it can
and then silently continues on its way.
The result is that two bad things happen: 1) we ignore other valid entries
within the netgroup containing the bogus entry, which prevents
us from interoperating with other systems that don't behave this way,
and 2) by printing an error to stderr from inside libc, we hose certain
programs, in this case rlogind. In the problem report, Bill Fenner
noted that the 'B' from 'Bad' was missing, and that rlogind exited
immediately after generating the error. The missing 'B' is apparently
not caused by any problem in getnetgrent.c; more likely it's getting
swallowed up by rlogind somehow, and the error message itself causes
rlogind to become confused. I was able to duplicate this problem and
discovered that running a simple test program on my FreeBSD system
resulted in a properly formatted (if confusing) error, whereas triggering
the error by trying to rlogin to the machine yielded the missing 'B'
problem.
Anyway, the fixes for this are as follows:
- The error message has been reformatted so that it prints out more useful
information (e.g. Bad entry (somehost,-somedomain) in netgroup "foo").
We check for NULL entries so that we don't print '(null)' anymore too. :)
- Rearranged things in parse_netgrp() so that we make a best guess at
what bad entries are supposed to look like and then continue processing
instead of bailing out.
- Even though the error message has been cleaned up, it's wrapped inside
a #ifdef DEBUG. This way we match the behavior of other systems. Since we
now handle the error condition better anyway, this error message becomes
less important.
PR #507 is another case of inconsistency. The code that handles
duplicate/circular netgroup entries isn't really 'too greedy; -- it's
just too noisy. If you have a netgroup containing duplicate entries,
the code actually does the right thing, but it also generates an error
message. As with the 'Bad netgroup' message, spewing this out from
inside libc can also hose certain programs (like rlogind). Again, no
other system generates an error message in this case.
The only change here is to hide the error message inside an #ifdef DEBUG.
Like the other message, it's largely superfluous since the code handles
the condition correctly.
Note that PR #510 (+@netgroup host matching in /etc/hosts.equiv) is still
being investigated. I haven't been able to duplicate it myself, and I
strongly suspect it to be a configuration problem of some kind. However,
I'm leaving all three PRs open until I get 510 resolved just for the
sake of paranoia.
SLIP device.
2) Don't directly frob the IFF_UP flag - use if_up/if_down as it was
intended.
3) Return ENETDOWN if IFF_UP isn't set when outputing, drop the packet if
if IFF_UP isn't set when inputing.
quotacheck -a will fail after the first partition (because
dev_bsize is 512 and is messes up the superblock read of the second
partition)
Submitted by: dillon@best.com (Mattew Dillon)
arcihves of the mailing lists and usenet groups.
Renamed the last part "Appendicies"
Moved "PC hardware reference" to the Appendicies section and added
an introduction.
Fixed a dangling cross reference. (submitters.sgml)
its connection parameters, we want to keep statistics on how often this
actually happens to see whether there is any work that needs to be done in
TCP itself.
Suggested by: John Wroclawski <jtw@lcs.mit.edu>
order, prevent suffix rule, if direct or children dependances exists,
forget to free v->name in var.c
My fixes: fix famous ^\t\n bug, correct free order in str_end
Reviewed by: bde
Obtained from: NetBSD, me
causes some clients that do not support linemode to mis-interpret the return
key (i.e. double returns).
The fix is to only do the state check for binary options if linemode will
be used.
Closes PR#505.
Submitted by: Charles Henrich
For the LKM_E_LOAD case of the DISPATCH() macro, use lkmexists() to
make sure we don't have another instance the module we're trying to
load already loaded _before_ calling the module's load() function.
If lkmexists() returns true, return EEXIST without trying to load
the module.
For most types of modules, the individual dispatch functions in the
kernel check for duplicated modules, but for LM_MISC we can't trust
the module to do the checks itself. Currently, the kernel does
do an lkmexists() check on LM_MISC modules, but not until after
the module's load() function has been called, which is too late
for it to do any good. If the load() function does irreversible
things to the kernel, the belated lkmexists() check forces an
unload() and a crash.
