Date: Sat, 26 Jan 2002 04:33:09 +0100 From: Cliff Sarginson <cliff@raggedclown.net> To: questions@freebsd.org Subject: Re: unlinking open files Message-ID: <20020126033309.GB1290@raggedclown.net> In-Reply-To: <0GQI0028YVW8VR@osfmail.rit.edu> References: <0GQI0028YVW8VR@osfmail.rit.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Jan 25, 2002 at 08:52:58PM -0500, Alex Ranaldi wrote: > Hello all, > > >From what I understand, if a file is open and deleted by the user (ie. an > apache log) problems will arise. For example, du and df will not display the > same value, as the kernel cannot free an open file. Even killing the process > using the file (in this case, Apache) will not help. Only a reboot seems to > solve the problem. > No that cannot be the case that you have to reboot to reclaim the space. If it is then you are the proud owner of an OS bug. But I do doubt this. It is a sometimes used programming practise to open a scratch file for some purpose and then immediately unlink it, this ensures any space it will take up is freed should the process die in error, or forget to unlink it before exiting. > I'm new to FreeBSD & Unix in general, but I was wondering why the user is not > warned before deleting a file that is in use. This seems like a rather > trivial thing to do, although I'm probably wrong. > > Any insight into this would be appreciated. > Mmm, this is to do with the way the file-system works. When you "delete" a file, you really decrement a count called the "link count" on a file, this is an entry in the inode (index node) for that file. This is because a file can have many links (read that as directory entries that all point to the same inode). When the file is closed if the link count is zero then the space is reclaimed. However it would not be so smart of the kernel to go cleaning that space up when some other process has that file open. The problem is that the file, no longer having a link count is invisible, or if it is apparently visible under the same name then it is in fact a new file with the same name as the "old" one. Having said all of that, this behaviour is confusing until you know about it (and even then is a pain). Perhaps it is somewhat suprising that no-one has thought of putting an optional switch in "rm" to check this out, although I do not see how it could be done reliably (between the time of checking the open status of a file, and the reporting of that status, the situation may have changed). Also purists would argue that it is outside of "rm's" remit to do so anyway. Statistically speaking I would say this must be a FAQ, that I don't believes appears in a FAQ, although any book on Unix should somewhere explain it (possibly less opaquely than I have managed above). -- Regards Cliff To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020126033309.GB1290>