Date: Fri, 6 Apr 2007 12:30:48 +0100 From: David Taylor <davidt@yadt.co.uk> To: FreeBSD Current <current@FreeBSD.org> Subject: Re: Surviving /dev/null disappearance Message-ID: <20070406113048.GA49739@outcold.yadt.co.uk> In-Reply-To: <461434A6.3080001@FreeBSD.org> References: <cb5206420704030216r44243573h7981c1e35ef7225@mail.gmail.com> <46128475.9060602@FreeBSD.org> <cb5206420704040151w3c4f32f7gfd4aa017d40a1199@mail.gmail.com> <4613D6F3.4080701@mac.com> <461434A6.3080001@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 04 Apr 2007, Maxim Sobolev wrote: > Chuck Swiger wrote: > >Andrew Pantyukhin wrote: > >>On 4/3/07, Maxim Sobolev <sobomax@freebsd.org> wrote: > >>>Patch ld(1) to detect the condition and don't unlink the device node? > >> > >>Yes, but there has to be a generic solution, so that > >>we don't reinvent the wheel for every one of the > >>thousands apps that may do this. > >> > >>Isn't there some safety-net wrapper function that > >>refuses to remove device nodes and maybe some other > >>types of files? > > > >Why not set a filesystem flag like schg on device nodes under a devfs > >tree...? > > Well, I suspect that it may cause ld(1) fail instead. What we want it to > do is to not perform unlink(2) before open(2) when -o argument is device > node. I think calling ld with it's output set to a device node is basically pilot error. ld unlinks files rather than truncating them for good reasons --- to avoid overwriting libraries that are in use (the unlinked file is still around on disk until the last fd referencing it is closed). -- David Taylor
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070406113048.GA49739>