Authentication-Results: mail-b.sr.ht; dkim=fail header.d=pixelhero.dev header.i=@pixelhero.dev Received: from out2.migadu.com (out2.migadu.com [188.165.223.204]) by mail-b.sr.ht (Postfix) with ESMTPS id 7685D11F001 for <~sircmpwn/public-inbox@lists.sr.ht>; Tue, 22 Nov 2022 00:58:34 +0000 (UTC) Message-ID: <60E2F85BE1287A8A3464D422FF42A80E@pixelhero.dev> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pixelhero.dev; s=key1; t=1669078713; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to; bh=spB1m4FIIylzLRXSjBGMVWtefijXxc9BzDUvwrnP+0k=; b=KVFLZpTk+qkTrie4lsaDPWTD9Wl0bet+YXiZatP4/LJiFmtXatUmmFBcEP0NQqerTRkxXE HGXgCQJqp6d41C/6+A6rBw4ftZElAqwJr8WQdbm9Pwo1s3bIOt3ezYUpKkXiC2cKA0w/wU kLxywKLsGQNTvEm0AgAz1l55mEAi2zvQOhVWftvBoRxOHErTokccaa5iPxDG2Y/6bZiyAQ dddeN6wsLzF+waBgDhrTSx7xX7fOMOwMKTVamM9ryUnjshc5Ybto1xkE6/cRGLLeixrC3L jRU3fX6UzwtUtGTJ3BgIwD+jL8lYV3f7X6BmQExKsHkIOD9fjpXiL6UxrZqQUQ== To: ecs@d2evs.net, noam@pixelhero.dev, safinaskar@gmail.com To: ~sircmpwn/public-inbox@lists.sr.ht Subject: Re: In praise of Plan 9: Plan 9 doesn't have true "mv"! Date: Mon, 21 Nov 2022 20:58:08 -0500 X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: noam@pixelhero.dev In-Reply-To: MIME-Version: 1.0 X-Migadu-Flow: FLOW_OUT Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 X-Migadu-Footer: yes Quoth Ember Sawady : > On Tue Nov 22, 2022 at 1:31 AM UTC, wrote: > > Renames are supported, but only within the same file system. They're not supported in _every_ case by mv(1) (currently, only within the same folder), but in principle it can be done. The main problem is that it's hard to know if two different folders are on the same file system. > Seems to me that you could just try the fast rename and fall back to a > copy if it fails, what's the reason that doesn't work? Imagine you have this directory structure: foo/ bar/ baz/ a.c and foo/ is bound over foo/bar, such that foo/bar/baz etc is equal to foo/baz, and the real, on-disk directory foo/bar *cannot* be accessed. If we tried a rename: % mv a.c ../bar/a.c On-disk, the following structure *should* exist: foo/ a.c bar/ baz/ However, if we tried renaming - and the fs let us - we'd instead see this: foo/ bar/ a.c baz/ mv(1) sees the absolute path, and cannot at present resolve it. With a copy, this does not matter: we go through the kernel to the file system to create the destination, and the kernel resolves the path for us. With a rename, though, it is not aware that we're writing a path at all, so it can't resolve it. In principle, I think this is solvable. Every process can read its own namespace in /proc/$PID/ns; mv could probably use that to - purely by looking at the list of mount paths - resolve the destination to be fs-local. We could also change the interface to the local mount system (devmnt) to expose it. This isn't a hard problem, really; it's just not an important one. If you held a gun to my head, I could probably have it solved on my local machine in an hour; getting a solution that would be accepted upstream would probably take longer. - Noam Preil