From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/3755 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Preparing to release 0.9.12 Date: Fri, 26 Jul 2013 02:18:30 -0400 Message-ID: <20130726061830.GV4284@brightrain.aerifal.cx> References: <20130724200221.GA4256@brightrain.aerifal.cx> <20130725104459.3c29fc34@vostro> <20130725161654.GH4284@brightrain.aerifal.cx> <20130725195955.25cbc101@vostro> <20130726003851.GA20873@newbook> <20130726081327.3d915b49@vostro> <20130726053420.GU4284@brightrain.aerifal.cx> <20130726090751.722d7ea2@vostro> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1374819521 6485 80.91.229.3 (26 Jul 2013 06:18:41 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 26 Jul 2013 06:18:41 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-3759-gllmg-musl=m.gmane.org@lists.openwall.com Fri Jul 26 08:18:45 2013 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1V2bMS-0006H0-5C for gllmg-musl@plane.gmane.org; Fri, 26 Jul 2013 08:18:44 +0200 Original-Received: (qmail 20475 invoked by uid 550); 26 Jul 2013 06:18:43 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 20467 invoked from network); 26 Jul 2013 06:18:42 -0000 Content-Disposition: inline In-Reply-To: <20130726090751.722d7ea2@vostro> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:3755 Archived-At: On Fri, Jul 26, 2013 at 09:07:51AM +0300, Timo Teras wrote: > On Fri, 26 Jul 2013 01:34:20 -0400 > Rich Felker wrote: > > > One thing to keep in mind with libc is that you want to be able to > > safely and atomically replace it during an upgrade without any > > intermediate state where the system is unusable. This means the actual > > filename (as opposed to symlink) needs to be something that does not > > change between versions. If, for example, you had: > > > > /lib/ld-musl-$(ARCH).so.1 -> /lib/musl.so.1.0.0 > > > > and wanted to upgrade to musl 1.0.1, you would have to change the > > symlink to point to a different name. But there is (as far as I know) > > no way to replace a symlink atomically; you have to unlink it first > > then make a new symlink. And this leaves a race window during which > > exec() could fail. > > man rename(2) says: > If oldpath refers to a symbolic link the link is renamed; if > newpath refers to a symbolic link the link will be overwritten. > > But if this is linux specific, and we want to support other operating > system kernels than linux, then this might be an issue. Oh, I was being stupid. Of course this isn't Linux-specific. See http://pubs.opengroup.org/onlinepubs/9699919799/functions/rename.html So if you want the unversioned name to be a symlink to the versioned one, then what you do is: symlink("/lib/musl.so.1.0.1", "/lib/tmp12345"); rename("/lib/tmp12345", "/lib/ld-musl-i386.so.1"); >From a shell script, however, it seems you need to explicitly perform these operations with ln and mv. The "ln -sf" command is specified to operate via unlink, rather than renaming a temporary link, so it has the race condition. This gives us some more flexibility in how the installation and links work. Rich