Date: 25 Jun 1996 00:08:26 -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: <4qnonq$261@twwells.com> References: <1.5.4.32.19960625205246.007b3a5c@dogbert.systems.sa.gov.au>
next in thread | previous in thread | raw e-mail | index | archive | help
In article <1.5.4.32.19960625205246.007b3a5c@dogbert.systems.sa.gov.au>, Garth T Kidd <garth@dogbert.systems.sa.gov.au> wrote: : Content-transfer-encoding: 7BIT : : [deliberately crashing machine, editing binary devices...] : : Yipe! I think I'll just put up with the file being missing... Actually, crashing your machine is pretty safe, especially if the machine is idled. To make it idle, log off everyone, shut down special systems (e.g., innd is best shut down by using ctlinnd, not a kill), kill all user processes (except the one keeping the file open), kill all system processes other than 0-4 and the gettys, sync, wait a few seconds, and then do the reset. Not that all this is necessary; Unix systems are, by and large, pretty good about dealing with crashes. Someone said that you have to manually fsck, which means rebooting into single-user mode and running fsck; this is possible but I doubt it. The reason given was that the inode would be cleared on a normal fsck. My recollection is that this is true if the file is of size zero; otherwise, it goes into lost+found. On the other hand, it can't hurt to manually fsck....
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4qnonq$261>