fs_contigdirs, fs_avgfilesize and fs_avgfpdir. This could cause
panics if these fields were zeroed while a filesystem was mounted
read-only, and then remounted read-write.
Add code to ffs_reload() which copies the fs_contigdirs pointer
from the previous superblock, and reinitialises fs_avgf* if necessary.
Reviewed by: mckusick
possible to use old generated doc-* files as the source for new ones.
Wrong -mdoc files would then be installed, and man(1) failed with the
following diagnostics:
mdoc error: end-macro (.em) respecification is not allowed. (#41)
Should this have been `.Em ...'?
Put helper stuff into `beforedepend' to cleanup old files.
Makefile first infected in rev 1.15.
Reported via: -current
always look up -network and -mask addresses numerically before
trying getnetbyname(). Without this, we may end up attempting DNS
queries on silly names such as "127.0.0.0.my-domain.com". See the
commit log from revisions 1.21 and 1.20 for further details.
removes the last path component until the mount() succeeds. However,
the code never checks if it has passed the mountpoint, so in some
cases where the mount() never succeeds, it can end up applying the
flags from a mounted filesystem to the underlying one.
Add a sanity check to the code which removes the last path component:
test that the fsid associated with the new path is the same as that
of the old one.
PR: bin/7872
With the recent changes in the CAM error handling, some problems in
the error handling of sa(4) have been uncovered. Basically, a number
of conditions that are not actually errors have been mistreated as
genuine errors. In particular:
. Trying to read in variable length mode with a mismatched blocksize
between the on-tape (virtual) blocks and the read(2) supplied buffer
size, causing an ILI SCSI condition, have caused an attempt to retry
the supposedly `errored' transfer, causing the tape to be read
continuously until it eventually hit EOM. Since by default any
simple mt(1) operation does an initial test read, an `mt stat' was
sufficient to trigger this bug.
Note that it's Justin's opinion that treating a NO SENSE as an EIO
is another bug in CAM. I feel not authorized to fix cam_periph.c
without another confirmation that i'm on the right track, however.
. Hitting a filemark caused the read(2) syscall to return EIO, instead
of returning a `short read'. Note that the current fix only solves
this problem in variable length mode. Fixed length mode uses a
different code path, and since i didn't grok all the intentions behind
that handling, i did not touch it (IOW: it's still broken, and you get
an EIO upon hitting a filemark).
The solution is to keep track of those conditions inside saerror(),
and upon completion to not call cam_periph_error() in that case. We
need to make sure that the device gets unfrozen if needed though (in
case of actual errors, cam_periph_error() does this on our behalf).
Not objected by: mjacob (who currently doesn't have the time to
review the patch)
