From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2 autolearn=ham autolearn_force=no version=3.4.4 Received: from tb-ob0.topicbox.com (tb-ob0.topicbox.com [64.147.108.117]) by inbox.vuxu.org (Postfix) with ESMTP id 51C7C2104E for ; Sat, 6 Apr 2024 05:18:53 +0200 (CEST) Received: from tb-mx0.topicbox.com (tb-mx0.nyi.icgroup.com [10.90.30.73]) by tb-ob0.topicbox.com (Postfix) with ESMTP id 1E7EB215C0 for ; Fri, 5 Apr 2024 23:18:53 -0400 (EDT) (envelope-from bounce.mM8abb414d4890eefbbbe7ef96.r522be890-2105-11eb-b15e-8d699134e1fa@9fans.bounce.topicbox.com) Received: by tb-mx0.topicbox.com (Postfix, from userid 1132) id 1A7A51474D93; Fri, 5 Apr 2024 23:18:53 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=9fans.net; h=from:to :subject:message-id:references:in-reply-to:date:mime-version :content-type:content-transfer-encoding:list-help:list-id :list-post:list-subscribe:reply-to:list-unsubscribe; s=dkim-1; t=1712373533; x=1712459933; bh=nFEv6PMgyr7pSjTPfbmo9DK4ShZfK52b Ey/qAlNkWbI=; b=ZjVBPkKZnA42wMa+9dA8GNMglcQ4Zezzg7iNsYjnmbVUrZO+ Tz8k5ev21vKikNSITM+ywrb2/0nJ5bDnJwxQPNAoPpw4pcVTMTKfeQFHoX829NAo 2AnxcP5Wp1cgy/eG+Lxt6YBMCFnjSU0UUDejUEQPIQyv39/4QJ64sHt4n9o= From: moody@posixcafe.org To: 9fans <9fans@9fans.net> Subject: Re: [9fans] openat() Message-Id: <17123735270.469FFd7.853634@composer.9fans.topicbox.com> References: <17123537830.EbFe44.28920@composer.9fans.topicbox.com> In-Reply-To: Date: Fri, 5 Apr 2024 23:18:47 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=17123735271.aB0f.853634 Content-Transfer-Encoding: 7bit Topicbox-Policy-Reasoning: allow: sender is a member Topicbox-Message-UUID: 61a88bd0-f3c4-11ee-9216-20772b2d11b0 Archived-At: =?UTF-8?B?PGh0dHBzOi8vOWZhbnMudG9waWNib3guY29tL2dyb3Vwcy85?= =?UTF-8?B?ZmFucy9UNjc1ZTczN2U3NzZlNWE5Yy1NOGFiYjQxNGQ0ODkwZWVmYmJiZTdl?= =?UTF-8?B?Zjk2Pg==?= List-Help: List-Id: "9fans" <9fans.9fans.net> List-Post: List-Software: Topicbox v0 List-Subscribe: Precedence: list Reply-To: 9fans <9fans@9fans.net> List-Unsubscribe: , Topicbox-Delivery-ID: 2:9fans:437d30aa-c441-11e9-8a57-d036212d11b0:522be890-2105-11eb-b15e-8d699134e1fa:M8abb414d4890eefbbbe7ef96:1:DPpJdjhOkAvCc1uA62oMeIHed2vqfDcPeCT5ljaxqp0 --17123735271.aB0f.853634 Date: Fri, 5 Apr 2024 23:18:47 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable My two cents on this: What you _would_ want for this would be the ability to walk from the existi= ng fd, however the limits of 9p walk make this a bit impossible to implemen= t in a great way in my opinion. From walk(5): The fid must represent a directory unless zero path name elements(for just = cloning the fid) are specified. The fid must be valid in the current sessio= n and must not have been opened for I/O by an open or create message. Since not every fid is eligible for being walked from, in order to implemen= t opanat() in any way that would be better than just batching the fd2path a= nd open would be to keep a "last directory" associated, like what we do wit= h the string used to open it. Also worth mentioning that fd2path is not wit= hout its own problems, it's possible that the namespace has changed since t= he file has been opened so the same path may not work the second time. So t= agging the last directory Chan would be "more correct", but I am not sure h= ow useful this is. Answering some other comments made: > As I understand it from the rationale section on the linux man page, the call exists to avoid a race condition between=20 checking that a directory exists and doing something to a path=20 containing it. An additional motivator is providing the effect of=20 additional current working directories notably for Linux threads (which=20 presumably don't have their own. I think 'threads'=C2=A0 (processes that=20 share memory) on Plan 9 do???). Each process has it's own current working directory: % pwd /home/moody % @{cd /} % pwd % /home/moody > This is all based on the assumption that holding a file/directory open ke= eps it alive and in existence... which on Plan 9, I think it doesn't, does = it? As I understand it, remove can remove a file or directory that is open,= which is not like UNIX/Linux... >=20 Depends on the file server implementation, I find that for more synthetic f= iles they are indeed kept alive as long there is someone with a reference t= o the fid. This is identifiable if all the cleanup happens on clunks(destroyfid in lib= 9p), which only happen when a fid's refcount hits zero. For non-synthetic or more "disk" file servers the behavior can differ. Cwfs= does not keep the data around, readers that attempt to read a deleted file= , even if they already have a reference open to it will result in a phase e= rror. However 9front's ramfs keeps the data around. My test for this was as follows: win1% echo 'something' >/tmp/test win2% 
My two cents=
 on this:

What you _would_ want for this would be the ability to walk from the existi=
ng fd, however the limits of 9p walk make this a bit impossible to implemen=
t in a great way in my opinion. From walk(5):

The fid must represent a directory unless zero path name elements(for just =
cloning the fid) are specified. The fid must be valid in the current sessio=
n and must not have been opened for I/O by an open or create message.

Since not every fid is eligible for being walked from, in order to implemen=
t opanat() in any way that would be better than just batching the fd2path a=
nd open would be to keep a "last directory" associated, like what=
 we do with the string used to open it. Also worth mentioning that fd2path =
is not without its own problems, it's possible that the namespace has c=
hanged since the file has been opened so the same path may not work the sec=
ond time. So tagging the last directory Chan would be "more correct&qu=
ot;, but I am not sure how useful this is.

Answering some other comments made:
As I understand it from the rationale section on the linux man page, the call exists to avoid a race condition between=20 checking that a directory exists and doing something to a path=20 containing it. An additional motivator is providing the effect of=20 additional current working directories notably for Linux threads (which=20 presumably don't have their own. I think 'threads'  (proce= sses that=20 share memory) on Plan 9 do???).

Each process has it's own current = working directory: % pwd /home/moody % @{cd /} % pwd % /home/moody
This is all based on the assumption tha= t holding a file/directory open keeps it alive and in existence... which on= Plan 9, I think it doesn't, does it? As I understand it, remove can re= move a file or directory that is open, which is not like UNIX/Linux...

Depends on the file server i= mplementation, I find that for more synthetic files they are indeed kept al= ive as long there is someone with a reference to the fid. This is identifiable if all the cleanup happens on clunks(destroyfid in lib= 9p), which only happen when a fid's refcount hits zero. For non-synthetic or more "disk" file servers the behavior can di= ffer. Cwfs does not keep the data around, readers that attempt to read a de= leted file, even if they already have a reference open to it will result in= a phase error. However 9front's ramfs keeps the data around.

My test for this was as follows:
win1% echo = 9;something' >/tmp/test
win2% </tmp/test { sleep 10; ca= t }
win1% rm /tmp/test # observe the error(if any) on win2

So you= really can't assume either case.


Thanks,
moody

P.S.
I apologize for the = formatting, it seems my emails are not making it to the list when I attempt= to send them from my mail server so I had to copy this response in to the = web form.  I would like to figure out why if possible.
9fans / 9fans / see discussions + participants + delivery&n= bsp;options Permalink = --17123735271.aB0f.853634--