From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1GXgyq-0002SV-EI for garchives@archives.gentoo.org; Wed, 11 Oct 2006 16:30:52 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.8/8.13.6) with SMTP id k9BGRPZD000414; Wed, 11 Oct 2006 16:27:25 GMT Received: from iabervon.org (iabervon.org [66.92.72.58]) by robin.gentoo.org (8.13.8/8.13.6) with ESMTP id k9BGNsY0012119 for ; Wed, 11 Oct 2006 16:23:54 GMT Received: (qmail 20092 invoked by uid 1000); 11 Oct 2006 12:23:53 -0400 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 11 Oct 2006 12:23:53 -0400 Date: Wed, 11 Oct 2006 12:23:53 -0400 (EDT) From: Daniel Barkalow To: Gentoo Mailing List Subject: Re: [gentoo-user] Dumb question In-Reply-To: <452C714D.2030008@gt.rr.com> Message-ID: References: <452C714D.2030008@gt.rr.com> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Archives-Salt: 8d8baa08-3c69-4aaf-b93e-dcd41902d4ae X-Archives-Hash: 63ba00a3e2219eb96cb034666bbc2824 On Tue, 10 Oct 2006, Anthony E. Caudel wrote: > I have been using Gentoo for more than 2 years now and have always > wondered (but never asked - That's the "dumb" part) how Gentoo manages > to update a package that happens to be running at the time. > > Given that the old version (the one running) is deleted, how does it > manage to keep standing if you just cut its legs off? Userspace technically never "deletes" anything in the UNIX model; it either "truncates" it (not what's going on here) or it "unlinks" it. "Unlink" causes the file not to have the filename any more, and the kernel gets rid of files which aren't in use and have no name (of course, nobody can tell when or if this happens, aside from the disk not filling up, because there would be no way to look at the file anyway). If you look at /proc//maps for a program you've upgraded, you'll probably find funny notations in there, indicating that the file it's using is not the file that currently has that filename. ("truncate" and otherwise openning the file for writing actually affect the file, not the filename, and would therefore cause programs to crash if you overwrote them.) Technical terms: the file itself is called an "inode", and the name is a "dentry" (actually, the last part of the path, which is all that goes away in a single operation, is the dentry). A dentry stores the inode number of the inode at that path, and "unlink" removes the dentry. What's actually happening in an upgrade is "rename", which, as a single operation, unlinks any dentry with the destination path, links the source inode to the destination dentry, and unlinks the source dentry. This means that no program can see the path empty or with half of a file or see the file with two names. -Daniel *This .sig left intentionally blank* -- gentoo-user@gentoo.org mailing list