Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Tue, 20 Nov 2001 18:18:19 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Tue, 20 Nov 2001 18:18:09 -0500 Received: from mons.uio.no ([129.240.130.14]:8614 "EHLO mons.uio.no") by vger.kernel.org with ESMTP id ; Tue, 20 Nov 2001 18:17:52 -0500 To: "Dan Maas" Cc: Subject: Re: Swap In-Reply-To: <040701c17215$357711c0$1a01a8c0@allyourbase> From: Trond Myklebust Date: 21 Nov 2001 00:17:44 +0100 In-Reply-To: <040701c17215$357711c0$1a01a8c0@allyourbase> Message-ID: Lines: 18 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org >>>>> " " == Dan Maas writes: > But NFS still allows atomic rename() right? Isn't it considered > essential to write the new executable or library under a > different name, and then atomically rename() over the old one? > If you write() directly into the executable, you will get what > you deserve... Atomic rename works fine, on NFS, so if you just rename the old library, you're quite safe. The bugs start to surface if you: a) Reuse the the old library's inode by doing something along the lines of open("lib.so",O_TRUNC|O_WRONLY). or b) erase the old library. Cheers, Trond - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/