[6142] in Release_7.7_team
Re: Reworking liblocker
daemon@ATHENA.MIT.EDU (Quentin Smith)
Mon Dec 22 21:31:01 2008
Date: Mon, 22 Dec 2008 21:30:14 -0500 (EST)
From: Quentin Smith <quentin@MIT.EDU>
To: Evan Broder <broder@mit.edu>
cc: Greg Price <price@mit.edu>, Bill Cattey <wdc@mit.edu>,
release-team@mit.edu, athena10@mit.edu
In-Reply-To: <49504A6D.7000806@mit.edu>
Message-ID: <Pine.LNX.4.64L.0812222129060.10617@vinegar-pot.mit.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Flag: NO
X-Spam-Score: 0.00
On Mon, 22 Dec 2008, Evan Broder wrote:
> Greg Price wrote:
>> On Mon, Dec 22, 2008 at 12:20:17PM -0600, Evan Broder wrote:
>>
>>> When a symlink in /mit is deleted, cache that deletion for 10
>>> seconds ... should give humans enough time to do it by hand, if they
>>> so desire.
>>>
>>
>> What about `ln -nsf`? Does that work? I expect it does stat, unlink,
>> symlink. If it does work, we may want to say that's what humans
>> should be using. It's simpler from the user perspective, because you
>> can pretend it's one atomic action. Then the timeout needn't be so
>> long as 10 seconds.
>>
>> Greg
>>
>
> Yeah - see the zephyr discussion, r163 of MacAthena, and...an as yet
> uncommitted changeset to the Athena repo :)
>
> ln -nsf does the right thing, although note that the symlink(2) syscall
> does a stat on its own. I dropped the timeout to 0.5 seconds on the
> justification that a human can't possibly type that fast, but that
> syscalls can handle it.
What if you instead only cache the deletion per pid? That would allow
attach or ln to make an unlink(), symlink() pair at its leisure without
allowing the deleted state to "leak" into the environment.
--Quentin
