Date: 25 Jun 1996 16:00:16 -0400 From: bill@twwells.com (T. William Wells) To: freebsd-questions@freebsd.org Subject: Re: int link(const int inode, const char *name2) Message-ID: <4qpggg$g1r@twwells.com> References: <4qnonq$261@twwells.com> <199606251834.LAA00270@phaeton.artisoft.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In article <199606251834.LAA00270@phaeton.artisoft.com>, Terry Lambert <terry@lambert.org> wrote: : A zero reference count file will be assumed to be a temp file and : cleared. That's certainly not my recollection. : cleared. A file with a non-zero reference an n-1 or fewer real : references for a count fo n will go into lost+found on automatic fsck. If a file has _any_ references, it _will not_ go into lost+found. Instead, its reference count will be adjusted to reflect the actual link count. : There is also the danger that the recovery process could not be : initiated successfully if the system starupt created files and : (potentially) reused blocks from the file (probability depends on : file size relative to disk size times number of blocks allocated : for temp files of one kind or another on startup on that disk. Now I'm completely convinced you don't know what you're talking about. One of two conditions obtains at boot: either the inode remains on disk and so it holds the data blocks or the inode does not. If the former, the system startup can create files till the fs is full and the file's data won't be touched. If the latter, the file is already gone, gone, gone and it'll be nearly impossible to recover the data, no matter what the startup does.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4qpggg$g1r>