Date: Wed, 08 May 1996 14:53:38 -0700 From: Scott Blachowicz <scott@statsci.com> To: michael butler <imb@scgt.oz.au> Cc: nate@sri.MT.net (Nate Williams), stable@freebsd.org Subject: Re: FS corruption during rm -fr Message-ID: <m0uHHAw-000r3tC@main.statsci.com> In-Reply-To: Your message of "Tue, 07 May 1996 04:29:39 %2B1000." <199605061829.EAA01152@asstdc.scgt.oz.au> References: <199605061829.EAA01152@asstdc.scgt.oz.au>
next in thread | previous in thread | raw e-mail | index | archive | help
michael butler <imb@scgt.oz.au> wrote:
> This seems to be two problems .. a quirk in the kernel plus a reference
> count problem for which Terry's been trying to get a patch into fsck for
> some time. fsck should "fix" it the first time ..
I don't know if this is related to the problem at hand, but...
I've seen similar sorts of problems on FreeBSD 2.0.5-R & 2.1.0-R systems
using rdist-6.1.0. I used to have some rules that did something like
this:
(bin/*) -> ( ${all} )
install /usr/adm/bin/.;
that "/." ending to the install target is supposed to indicate that the
destination is to be a directory (created by rdistd as necessary). The
problem is that if the wildcard "bin/*" expanded to only one file, then
the default for the install destination is "regular file" instead of
directory into which the file should be placed. To force the
interpretation as directory, I used the "/." suffix.
When rdistd created the directory, I would end up with a directory that I
couldn't remove. What I would do is rename the destination directory to
something out of the way (in the specific case in question, I wanted it to
be a symlink to a different spot instead of a directory in that location),
then the next time fsck ran the oddball directory got reaped.
Now, one could probably argue that rdistd might've been creating the
directory incorrectly (and maybe CVS is doing the same thing), but I
wouldn't think that it should be possible to get into the end result
situation through "normal use"...some system call should've returned an
error or the situation should've been handled as expected.
Scott Blachowicz Ph: 206/283-8802x240 Mathsoft (Data Analysis Products Div)
1700 Westlake Ave N #500
scott@statsci.com Seattle, WA USA 98109
Scott.Blachowicz@seaslug.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?m0uHHAw-000r3tC>