Return to BSD News archive
Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!agate!agate.berkeley.edu!cgd
From: cgd@eden.CS.Berkeley.EDU (Chris G. Demetriou)
Newsgroups: comp.os.386bsd.development
Subject: Re: File Truncation Philosophy
Date: 1 Apr 93 20:53:45
Organization: Kernel Hackers 'r' Us
Lines: 27
Message-ID: <CGD.93Apr1205345@eden.CS.Berkeley.EDU>
References: <C4tJ6C.C17@ns1.nodak.edu> <CGD.93Apr1173018@eden.CS.Berkeley.EDU>
<C4u8y2.HCM@ns1.nodak.edu>
NNTP-Posting-Host: eden.cs.berkeley.edu
In-reply-to: tinguely@plains.NoDak.edu's message of Fri, 2 Apr 1993 04:10:50 GMT
[ <sigh> i see i still didn't answer your question; i really ought to
shut up and do real work... 8-]
In article <C4u8y2.HCM@ns1.nodak.edu> tinguely@plains.NoDak.edu (Mark Tinguely) writes:
>the request is ideas how many problems will be introduced by changing this?
>If it is changed, where should it be change? maybe executing program can
>have it's inode protected from truncation, or other low changes to how
>truncation of a inode.
umm, problems that would be introduced by changing it:
and program which depends on files keeping the same inode
would be "buggified" by this change. i believe that
"tail -f" would be the most commonly-used example of this...
(as i mentioned) i think the change should be made the the
programs which cause the truncation/replacement of files,
but *only* to those programs whose job it is update/replace
running programs.
chris
--
Chris G. Demetriou cgd@cs.berkeley.edu
"386bsd as depth first search: whenever you go to fix something you
find that 3 more things are actually broken." -- Adam Glass