From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/3754 Path: news.gmane.org!not-for-mail From: Timo Teras Newsgroups: gmane.linux.lib.musl.general Subject: Re: Preparing to release 0.9.12 Date: Fri, 26 Jul 2013 09:07:51 +0300 Message-ID: <20130726090751.722d7ea2@vostro> 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> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1374818855 32089 80.91.229.3 (26 Jul 2013 06:07:35 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 26 Jul 2013 06:07:35 +0000 (UTC) Cc: dalias@aerifal.cx To: musl@lists.openwall.com Original-X-From: musl-return-3758-gllmg-musl=m.gmane.org@lists.openwall.com Fri Jul 26 08:07:36 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 1V2bBb-0002sQ-Pu for gllmg-musl@plane.gmane.org; Fri, 26 Jul 2013 08:07:31 +0200 Original-Received: (qmail 15529 invoked by uid 550); 26 Jul 2013 06:07:31 -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 15519 invoked from network); 26 Jul 2013 06:07:31 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:in-reply-to:references :x-mailer:mime-version:content-type:content-transfer-encoding; bh=r6HzC9w80b/vE6IkXeG5hRDqOO4ijhNlbiA2WVXynMc=; b=siAC+4FYfRv7EngNjg9zy13QMNlIe/vFRWWEd/34wrbxfgrqcud/FiQhISjg/Iygy+ 7cYyweGK6IyNP6f/k5PGSgjpecKfJvvK7g3tH7K5ve6EyuM7cdTisIu+SmPvTfFG5uFv PiRPMZpyavbPur7wJ4YWeGKW6bQtzp8ss0MJlrQe+3lMzEF9qcQp++t+OgVzYnyuwIpM CtJgrK+PETDuUKbHLIsZEVMcd+asuEeFs0wO7MDtOGTlTQ/4R7VuerZNsfNKWmZW9hrY 0Tw7QYzLfnV/u5OLFuPgzFyL4SOLZlwKzMYAeCy3lRb2bE0z8zqfOvwV3DhevwSCIJfE NPmA== X-Received: by 10.14.205.196 with SMTP id j44mr1437200eeo.96.1374818839435; Thu, 25 Jul 2013 23:07:19 -0700 (PDT) Original-Sender: =?UTF-8?Q?Timo_Ter=C3=A4s?= In-Reply-To: <20130726053420.GU4284@brightrain.aerifal.cx> X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.20; i686-pc-linux-gnu) Xref: news.gmane.org gmane.linux.lib.musl.general:3754 Archived-At: 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. - Timo