From owner-freebsd-current Sun Mar 5 13:58:48 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id NAA02680 for current-outgoing; Sun, 5 Mar 1995 13:58:48 -0800 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id NAA02584 for ; Sun, 5 Mar 1995 13:57:57 -0800 Received: from sax.sax.de by irz301.inf.tu-dresden.de with SMTP (5.67b+/DEC-Ultrix/4.3) id AA22742; Sun, 5 Mar 1995 22:54:52 +0100 Received: by sax.sax.de (8.6.9/8.6.9-s1) with UUCP id WAA12472 for freebsd-current@FreeBSD.org; Sun, 5 Mar 1995 22:54:52 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.6.9/8.6.9) id WAA01795 for freebsd-current@FreeBSD.org; Sun, 5 Mar 1995 22:54:48 +0100 From: J Wunsch Message-Id: <199503052154.WAA01795@uriah.heep.sax.de> Subject: Re: "Text file busy" with program not running anymore? To: freebsd-current@FreeBSD.org (FreeBSD-current users) Date: Sun, 5 Mar 1995 22:54:47 +0100 (MET) In-Reply-To: <199503052133.NAA00248@corbin.Root.COM> from "David Greenman" at Mar 5, 95 01:33:08 pm Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 866 Sender: current-owner@FreeBSD.org Precedence: bulk As David Greenman wrote: > > ... I can > see no valid justification for preventing writes to executing files. If you > really don't want your executing process(es) to die, then unlinking the file > first is this the thing to do. OOOOOH NOOOOO! Please, don't do that! I've personally experienced this ``feature'' on two systems (DG/UX and IRIX), all i can say: IT IS BUGGING PEOPLE. If you do get the "text file busy", okay, you know what's happening. Show me that sysadmin who is really aware of each single binary running (out of > 100 procs) and who knows that none of the files he's just going to upgrade is still active. Btw., i think install(1)'s feature to unlink the file first relies on seeing the ETXTBSY. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ Never trust an operating system you don't have sources for. ;-)