From: Michael Sullivan <michael@espersunited.com>
To: gentoo-user@lists.gentoo.org
Subject: Re: [gentoo-user] Dumb question
Date: Wed, 11 Oct 2006 12:43:04 -0500 [thread overview]
Message-ID: <1160588584.14476.28.camel@camille.gateway.2wire.net> (raw)
In-Reply-To: <Pine.LNX.4.64.0610111201050.9789@iabervon.org>
On Wed, 2006-10-11 at 12:23 -0400, Daniel Barkalow wrote:
> 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/<PID>/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*
Wow, files can exist without file names. I think I found a topic for
discussion in philosophy class...
--
gentoo-user@gentoo.org mailing list
next prev parent reply other threads:[~2006-10-11 17:48 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-10-11 4:21 [gentoo-user] Dumb question Anthony E. Caudel
2006-10-11 4:42 ` Troy Curtis Jr
2006-10-11 6:20 ` Nick Rout
2006-10-11 18:05 ` Thomas T. Veldhouse
2006-10-11 18:29 ` Neil Bothwick
2006-10-11 6:30 ` Anthony E. Caudel
2006-10-11 8:28 ` Neil Bothwick
2006-10-11 7:44 ` Pawel Kraszewski
2006-10-11 16:23 ` Daniel Barkalow
2006-10-11 17:43 ` Michael Sullivan [this message]
2006-10-12 7:28 ` Alan McKinnon
2006-10-12 6:17 ` Anthony E. Caudel
2006-10-12 6:22 ` Bo Ørsted Andresen
2006-10-12 6:42 ` PaulNM
2006-10-12 7:30 ` Alan McKinnon
2006-10-12 11:55 ` Boyd Stephen Smith Jr.
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1160588584.14476.28.camel@camille.gateway.2wire.net \
--to=michael@espersunited.com \
--cc=gentoo-user@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox