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.7 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED,DKIM_VALID,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: from tb-ob1.topicbox.com (tb-ob1.topicbox.com [64.147.108.173]) by inbox.vuxu.org (Postfix) with ESMTP id 493A3267F3 for ; Sat, 6 Apr 2024 19:36:25 +0200 (CEST) Received: from tb-mx1.topicbox.com (tb-mx1.nyi.icgroup.com [10.90.30.61]) by tb-ob1.topicbox.com (Postfix) with ESMTP id B6EB337879 for ; Sat, 6 Apr 2024 13:36:22 -0400 (EDT) (envelope-from bounce.mM3c953ec4ad1db560805d02b3.r522be890-2105-11eb-b15e-8d699134e1fa@9fans.bounce.topicbox.com) Received: by tb-mx1.topicbox.com (Postfix, from userid 1132) id AE8511269FD1; Sat, 6 Apr 2024 13:36:22 -0400 (EDT) ARC-Authentication-Results: i=2; topicbox.com; arc=pass; dkim=pass (2048-bit rsa key sha256) header.d=gmail.com header.i=@gmail.com header.b=GQZXGIw8 header.a=rsa-sha256 header.s=20230601 x-bits=2048; dmarc=pass policy.published-domain-policy=none policy.published-subdomain-policy=quarantine policy.applied-disposition=none policy.evaluated-disposition=none (p=none,sp=quarantine,d=none,d.eval=none) policy.policy-from=p header.from=gmail.com; spf=pass smtp.mailfrom=rminnich@gmail.com smtp.helo=mail-lj1-f175.google.com; x-internal-arc=fail (as.1.topicbox.com=pass, ams.1.topicbox.com=fail (message has been altered)) (Message modified while forwarding at Topicbox) ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d= topicbox.com; h=mime-version:references:in-reply-to:from:date :message-id:subject:to:content-type:list-help:list-id:list-post :list-subscribe:reply-to:content-transfer-encoding :list-unsubscribe; s=sysmsg-1; t=1712424982; bh=n5MRUEjon9SXKlUz geBJZN+npflTfd5ucsG3sscbjpY=; b=Kfyp4PAS+PVR7nY84WIr3hMlKHrfKL20 t+hMgoeJkJA0VFKRRW04Xl5f1XUz11yF3f/dQpr9qGPIxPCAlEW1P5eGZ3LS+TZC MwoKs3FubGTWiyofCiSGrBBsSKb7mDntJjha6pJso9a/X1eGNDYW2y0A/gswBZqj DDH1VBXUn+M= ARC-Seal: i=2; a=rsa-sha256; cv=pass; d=topicbox.com; s=sysmsg-1; t= 1712424982; b=Jm3rTqH8bcgkzJ3caoiPttr0nd/L3v9fZz/Q8/PCDDFtsksrp7 EQyd7AB3cKitMgSELens4yqpmgjoMGByYTBqF2lP/pVkUXfphZf/txrVdZwur0Zd SxgJj0p324q4yjvtc/gHNmQP1qK18qkKicvUl2YOpa5A3mMZuuOdjmPwU= Authentication-Results: topicbox.com; arc=pass; dkim=pass (2048-bit rsa key sha256) header.d=gmail.com header.i=@gmail.com header.b=GQZXGIw8 header.a=rsa-sha256 header.s=20230601 x-bits=2048; dmarc=pass policy.published-domain-policy=none policy.published-subdomain-policy=quarantine policy.applied-disposition=none policy.evaluated-disposition=none (p=none,sp=quarantine,d=none,d.eval=none) policy.policy-from=p header.from=gmail.com; spf=pass smtp.mailfrom=rminnich@gmail.com smtp.helo=mail-lj1-f175.google.com; x-internal-arc=fail (as.1.topicbox.com=pass, ams.1.topicbox.com=fail (message has been altered)) (Message modified while forwarding at Topicbox) X-Received-Authentication-Results: tb-mx0.topicbox.com; arc=none (no signatures found); bimi=skipped (DMARC Policy is not at enforcement); dkim=pass (2048-bit rsa key sha256) header.d=gmail.com header.i=@gmail.com header.b=GQZXGIw8 header.a=rsa-sha256 header.s=20230601 x-bits=2048; dmarc=pass policy.published-domain-policy=none policy.published-subdomain-policy=quarantine policy.applied-disposition=none policy.evaluated-disposition=none (p=none,sp=quarantine,d=none,d.eval=none) policy.policy-from=p header.from=gmail.com; iprev=pass smtp.remote-ip=209.85.208.175 (mail-lj1-f175.google.com); spf=pass smtp.mailfrom=rminnich@gmail.com smtp.helo=mail-lj1-f175.google.com; x-aligned-from=pass (Address match); x-google-dkim=pass (2048-bit rsa key) header.d=1e100.net header.i=@1e100.net header.b=DgAZ/wfa; x-me-sender=none; x-ptr=pass smtp.helo=mail-lj1-f175.google.com policy.ptr=mail-lj1-f175.google.com; x-return-mx=pass header.domain=gmail.com policy.is_org=yes (MX Records found: alt3.gmail-smtp-in.l.google.com,alt1.gmail-smtp-in.l.google.com,alt2.gmail-smtp-in.l.google.com,gmail-smtp-in.l.google.com,alt4.gmail-smtp-in.l.google.com); x-return-mx=pass smtp.domain=gmail.com policy.is_org=yes (MX Records found: alt3.gmail-smtp-in.l.google.com,alt1.gmail-smtp-in.l.google.com,alt2.gmail-smtp-in.l.google.com,gmail-smtp-in.l.google.com,alt4.gmail-smtp-in.l.google.com); x-tls=pass smtp.version=TLSv1.2 smtp.cipher=ECDHE-RSA-AES256-GCM-SHA384 smtp.bits=256/256; x-vs=clean score=0 state=0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=9fans.net; h= mime-version:references:in-reply-to:from:date:message-id:subject :to:content-type:list-help:list-id:list-post:list-subscribe :reply-to:content-transfer-encoding:list-unsubscribe; s=dkim-1; t=1712424982; x=1712511382; bh=W1x/aGdDC7uL2r6X/hbBfamPIVKdooTf /X7yYONX4Q0=; b=Q1DGkeKYjPDHWaKRngQE+CZytMtfLQc6SCy4OKTy0428oZhk Hwq+AWWf3JcQh5gIHq1hsQZhcNCnjDesu27jNcTJfuGpWQR0LTfxKaHiAuQ787dq EaWV5tbLbwIMPwTFmeY9cHn4VOJVXuTZwLzNujMHaZ/CgopX16u3uGWqsKg= Received: from tb-mx0.topicbox.com (localhost.local [127.0.0.1]) by tb-mx0.topicbox.com (Postfix) with ESMTP id 5E762147C031 for <9fans@9fans.net>; Sat, 6 Apr 2024 13:36:10 -0400 (EDT) (envelope-from rminnich@gmail.com) Received: from tb-mx0.topicbox.com (localhost [127.0.0.1]) by tb-mx0.topicbox.com (Authentication Milter) with ESMTP id 482B798A961; Sat, 6 Apr 2024 13:36:10 -0400 ARC-Seal: i=1; a=rsa-sha256; cv=none; d=topicbox.com; s=arcseal; t= 1712424970; b=hwCS8ekXuk1sAPeRNi0HktqcEoM3+MnaufLQgAsxZ0JEnm3SGz umMPcURRXxaQpgngTH6YCRAqmtUuzH/gB5IvWvFdz3sHFXoTe7PdAn9NkNH2tRIc NNrZgGreNjlJhEQ9fEur8iNpo8vVNg1+QltKd5Otxydvee9y9rP6hvyhkAgWToEI PUm3/FuAFv8XhOFC4ZH6uHcMtfe7VoHQ3VDn8NArjf4WJrWMrR9XunY/J7iVyWtG /F/UYaVSvmFkdHX8u8ZPRIMfBSNuskxAsUulz29C9iQWHx1ZHi1SqfjnoRAhhEtS V8K+/qh9UMbwxHCqVekCHjGHjAb9fxVYoESQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d= topicbox.com; h=mime-version:references:in-reply-to:from:date :message-id:subject:to:content-type; s=arcseal; t=1712424970; bh=3ygfiOkT4T5DaOmhbuebsj5A2KMKWjYeI1d1Rqi/QvI=; b=SDuX4MojvfuD k4kUHoHhq+o4apW8C8lvPXHSntCCxYJiWVFFlO5oNWqT1EnQOaEVp1AK3fQyyOh3 c4pZMulIKAbeTt8y7B5AZvfDMbAsrfn5vHSsJnBTkEkOetirWRo9XX0rEtA88yoC Tlr69iZsUENA85nws5u9FV5ht5JTM08ENYBcHFhooNbn5QYcLLwhOglt10gF+1zo jVZNahSOLZ/l3WuL3ICZP+NDbreL7+AB6asnn6RwilXrGGCvnu4ViBFArl0H4U2O a8jCgpXBRDamVFGFtS1RL8C35E22TCS2PkKNwWxW0XUMDiQWN1AvtWuqWvQhSYyt 8S3Y1r3H9g== ARC-Authentication-Results: i=1; tb-mx0.topicbox.com; arc=none (no signatures found); bimi=skipped (DMARC Policy is not at enforcement); dkim=pass (2048-bit rsa key sha256) header.d=gmail.com header.i=@gmail.com header.b=GQZXGIw8 header.a=rsa-sha256 header.s=20230601 x-bits=2048; dmarc=pass policy.published-domain-policy=none policy.published-subdomain-policy=quarantine policy.applied-disposition=none policy.evaluated-disposition=none (p=none,sp=quarantine,d=none,d.eval=none) policy.policy-from=p header.from=gmail.com; iprev=pass smtp.remote-ip=209.85.208.175 (mail-lj1-f175.google.com); spf=pass smtp.mailfrom=rminnich@gmail.com smtp.helo=mail-lj1-f175.google.com; x-aligned-from=pass (Address match); x-google-dkim=pass (2048-bit rsa key) header.d=1e100.net header.i=@1e100.net header.b=DgAZ/wfa; x-me-sender=none; x-ptr=pass smtp.helo=mail-lj1-f175.google.com policy.ptr=mail-lj1-f175.google.com; x-return-mx=pass header.domain=gmail.com policy.is_org=yes (MX Records found: alt3.gmail-smtp-in.l.google.com,alt1.gmail-smtp-in.l.google.com,alt2.gmail-smtp-in.l.google.com,gmail-smtp-in.l.google.com,alt4.gmail-smtp-in.l.google.com); x-return-mx=pass smtp.domain=gmail.com policy.is_org=yes (MX Records found: alt3.gmail-smtp-in.l.google.com,alt1.gmail-smtp-in.l.google.com,alt2.gmail-smtp-in.l.google.com,gmail-smtp-in.l.google.com,alt4.gmail-smtp-in.l.google.com); x-tls=pass smtp.version=TLSv1.2 smtp.cipher=ECDHE-RSA-AES256-GCM-SHA384 smtp.bits=256/256; x-vs=clean score=0 state=0 X-ME-VSCause: gggruggvucftvghtrhhoucdtuddrgedvledrudegvddgudduiecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpggftfghnshhusghstghrihgsvgdp uffrtefokffrpgfnqfghnecuuegrihhlohhuthemuceftddtnecunecujfgurhepgghfjg fhfffkuffvtgesrgdtreertddtjeenucfhrhhomheprhhonhcumhhinhhnihgthhcuoehr mhhinhhnihgthhesghhmrghilhdrtghomheqnecuggftrfgrthhtvghrnhephfehteetue dvgedthffhieegfffhjeefjeeiteffffeiuddvhefhffduiedutdeunecuffhomhgrihhn pehtohhpihgtsghogidrtghomhenucfkphepvddtledrkeehrddvtdekrddujeehnecuve hluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehinhgvthepvddtledrkeehrddvtdek rddujeehpdhhvghlohepmhgrihhlqdhljhduqdhfudejhedrghhoohhglhgvrdgtohhmpd hmrghilhhfrhhomhepoehrmhhinhhnihgthhesghhmrghilhdrtghomheqpdhnsggprhgt phhtthhopedupdhrtghpthhtohepoeelfhgrnhhsseelfhgrnhhsrdhnvghtqe X-ME-VSScore: 0 X-ME-VSCategory: clean Received-SPF: pass (gmail.com ... _spf.google.com: Sender is authorized to use 'rminnich@gmail.com' in 'mfrom' identity (mechanism 'include:_netblocks.google.com' matched)) receiver=tb-mx0.topicbox.com; identity=mailfrom; envelope-from="rminnich@gmail.com"; helo=mail-lj1-f175.google.com; client-ip=209.85.208.175 Received: from mail-lj1-f175.google.com (mail-lj1-f175.google.com [209.85.208.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tb-mx0.topicbox.com (Postfix) with ESMTPS for <9fans@9fans.net>; Sat, 6 Apr 2024 13:36:09 -0400 (EDT) (envelope-from rminnich@gmail.com) Received: by mail-lj1-f175.google.com with SMTP id 38308e7fff4ca-2d4360ab3daso36712051fa.3 for <9fans@9fans.net>; Sat, 06 Apr 2024 10:36:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712424967; x=1713029767; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=3ygfiOkT4T5DaOmhbuebsj5A2KMKWjYeI1d1Rqi/QvI=; b=DgAZ/wfafpNM3IKg/7Pi8RJAoEeWdX8F0eHboPGjzQ7K+BB/f0emv8+C70oozR+ekb /g0c1DUl3wcdaUb0pDj3FfXwFYJI3MsbNl/Y0nlDEyESSCmCdyc+D++QIWIBwIZDd9lx FL+fVhj7rqUL5LOHtzC00Ng67wKoit9i5JurIE2GM8hRy+NKeZfAXIpm2Uz7/a71PUrN t6HTEzjUQzrgflaUeJCoEk1WmMxy4M+bk7lZ4NyvWtPc0lK9STJpZCxucOcIhIjKz1zu IQQMHlkvi0pKrn3pas6QW8Wg5s+xHJi25SmPxiMjiSGWmjLzqbQv+Nw0B/sEQtawOPwW xmUg== X-Gm-Message-State: AOJu0Yy/AlGn2lFxkFqvHw9DtvgBP3p6IDng3A8ALnjXcc77A3Tp2+41 ETmEUdwLpa6OUyz21QNnGxJ2txtp7tH+tJQhVp1ZLUJi8YM3Kugd6gXYeebLvpeSNprPh6kKMBa MwRjAiFHKigqogI82F4jMwZd3RgzdOFnm X-Google-Smtp-Source: AGHT+IEz7eE/W1ewfDO0KtYEWvLaStGoc1JNmb2ydQgsEFMAKN7iue/aR0+vLsu1jqPEivjnDqJDm9LGwLqU8FIuv2Y= X-Received: by 2002:a19:9155:0:b0:515:e6bd:2f13 with SMTP id y21-20020a199155000000b00515e6bd2f13mr2542791lfj.15.1712424967019; Sat, 06 Apr 2024 10:36:07 -0700 (PDT) MIME-Version: 1.0 References: <17123537830.EbFe44.28920@composer.9fans.topicbox.com> <17123735270.469FFd7.853634@composer.9fans.topicbox.com> In-Reply-To: <17123735270.469FFd7.853634@composer.9fans.topicbox.com> From: ron minnich Date: Sat, 6 Apr 2024 10:35:54 -0700 Message-ID: Subject: Re: [9fans] openat() To: 9fans <9fans@9fans.net> Content-Type: multipart/alternative; boundary=000000000000dd279c061571019e Topicbox-Policy-Reasoning: allow: sender is a member Topicbox-Message-UUID: 2acad87a-f43c-11ee-9450-8077fb8b7b06 Archived-At: =?UTF-8?B?PGh0dHBzOi8vOWZhbnMudG9waWNib3guY29tL2dyb3Vwcy85?= =?UTF-8?B?ZmFucy9UNjc1ZTczN2U3NzZlNWE5Yy1NM2M5NTNlYzRhZDFkYjU2MDgwNWQw?= =?UTF-8?B?MmIzPg==?= List-Help: List-Id: "9fans" <9fans.9fans.net> List-Post: List-Software: Topicbox v0 List-Subscribe: Precedence: list Reply-To: 9fans <9fans@9fans.net> Content-Transfer-Encoding: 7bit List-Unsubscribe: , Topicbox-Delivery-ID: 2:9fans:437d30aa-c441-11e9-8a57-d036212d11b0:522be890-2105-11eb-b15e-8d699134e1fa:M3c953ec4ad1db560805d02b3:1:tJq4x3dcgjChIJCT5GijH4UeOZqaA0H7ErZwUetgfDI --000000000000dd279c061571019e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable openat gives you the effect of 'cd path; open file' without having to cd. I don't see a lot of benefit to it unless you're opening a lot of files at that path. My first reaction, assuming you have a lot of files in that directory, was something like bind /dir /n/x and then just open /n/x/file... for a lot of files. This would work for any system call that takes a path. The question I had was, can I get the benefit of *at without doing what linux is doing, namely, for all system calls with a path, make an '...at' version. I am guessing so, though I'm not sure it's as efficient. On Fri, Apr 5, 2024 at 8:19=E2=80=AFPM wrote: > My two cents on this: > > What you _would_ want for this would be the ability to walk from the exis= ting fd, however the limits of 9p walk make this a bit impossible to implem= ent in a great way in my opinion. From walk(5): > > The fid must represent a directory unless zero path name elements(for jus= t cloning the fid) are specified. The fid must be valid in the current sess= ion 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 implem= ent opanat() in any way that would be better than just batching the fd2path= and open would be to keep a "last directory" associated, like what we do w= ith the string used to open it. Also worth mentioning that fd2path is not w= ithout its own problems, it's possible that the namespace has changed since= the file has been opened so the same path may not work the second time. So= tagging the last directory Chan would be "more correct", 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 checking that a directory > exists and doing something to a path containing it. An additional motivat= or > is providing the effect of additional current working directories notably > for Linux threads (which presumably don't have their own. I think > 'threads' (processes that 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... > > > Depends on the file server implementation, I find that for more synthetic > files they are indeed kept alive as long there is someone with a reference > to the fid. This is identifiable if all the cleanup happens on > clunks(destroyfid in lib9p), 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 error. However 9front's ramfs keeps the data around. > > My test for this was as follows: > win1% echo 'something' >/tmp/test > win2% 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 options > Permalink > > ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T675e737e776e5a9c-M3c953= ec4ad1db560805d02b3 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription --000000000000dd279c061571019e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
openat gives you the effect of 'cd path; o= pen file' without having to cd. I don't see a lot of benefit to it = unless you're opening a lot of files at that path. 

My first reaction, assuming you have a lot of files in that director= y, was something like
bind /dir /n/x and then just open /n/x/file= ... for a lot of files. 

This would work fo= r any system call that takes a path.

The questio= n I had was, can I get the benefit of *at without doing what linux is doing= , namely, for all system calls with a path, make an '...at' version= .
I am guessing so, though I'm not sure it's as effi= cient.


On Fri, Apr 5, 2024 at 8:19 PM <moody@posixcafe.org> wrote:
=
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 
T=
his is all based on the assumption that 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 remove 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.
= --000000000000dd279c061571019e--