> I looked at a few of the emulator/linux* ports, and it was not in
> their pkg-plist files, only something in their usr/sbin
> (glibc_post_upgrad), which, when ran, does not generate a glibc that I
> can find in the any of BSDs lib directories, or the compat/linux/lib,
> compat/linux/usr/lib eithe
> The short answer is that fsck can detect the bad inodes and fix or
> delete them. Assuming no programming errors, you don't have to worry
> about a file containing bogus data after fsck has run. Unfortunately,
> if write-caching is enabled on your hard drive (and it probably is,
> for speed), t
Here goes a newbie question about classical FFS (without
softupdates).
As metadata is updated synchronously, can an i-node, at some
point, end pointing to not written yet data blocks? Is this a
security risk, i.e., can those pointed to data blocks pertain to
another user's deleted on memory but no
