--lc9FT7cWel8HagAv
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, May 15, 2002 at 10:15:31PM -0400, der Mouse wrote:
> I've done more experiments, and it appears that fsck torches
> unreferenced files, rather than putting them in lost+found, when their
> link count is zero (ie, they were still around only because they were
> open when the crash happened).

Fwiw, I agree with greywolf. This should REALLY be changed.

(I was able to recover the entirety of an Oracle DB whose backing
files had received an rm in the file system through Solaris's
/proc/<pid>/fd pointers on top of Veritas VXFS. I did it that way,
rather than fscking and hoping, because I didn't trust VXFS not to
do by accident exactly what we do on purpose with fsck_ffs. It'd
be really nice to be able to trust FFS not to do this.)

> But understandable, since an unreferenced file with zero link count is
> usually a file that "doesn't exist" as far as the filesystem namespace
> goes, referenceable only by processes that have it open somehow.

But that doesn't mean you don't want it. (Cf, huge file,
accidentally rm'ed, but still open in some application. You want
that file. Badly.)

> Annoyingly, even running fsck by hand didn't help - when I said no to
> CLEAR? it didn't offer me a RECONNECT? option.  If I'd really wanted
> the file contents I would have had to have used dumpi or equivalent, or
> patched a directory entry by hand to point to it.  That I definitely
> think needs fixing.

That doesn't strike me as the end of the world. If you've got the
inode in fsck_ffs, you've got the disk offsets. Just dd. (I'd have
done this with my VXFS restore, but three of the forty inodes had
been reused already as I didn't force the file system read-only
quickly enough.)

--=20
gabriel rosenkoetter
gr@eclipsed.net

--lc9FT7cWel8HagAv
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (NetBSD)

iD8DBQE8/OVU9ehacAz5CRoRAla6AJ97Y2h+jmKcnTIi0e16jElxVoTaZACfRIhY
le5tJs/se+j6CFDPOoNQO24=
=wzlg
-----END PGP SIGNATURE-----

--lc9FT7cWel8HagAv--