Authentication-Results: mail-b.sr.ht; dkim=pass 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 D6D1111F001 for <~sircmpwn/public-inbox@lists.sr.ht>; Tue, 22 Nov 2022 00:59:10 +0000 (UTC) Message-ID: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pixelhero.dev; s=key1; t=1669078750; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: 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=kRznHZp2JWWtR0EClHqmlGl76/aZJxTGlB39LTW+6IaGUpBgessu9BVKteZZOlQXIH5RJS NwfGjZQfp0uWeGt3vCBD7lAY9j+XiITosuKWbSCTctEQ+Li2hNzuNbR+djbv+TbiHkYXd7 nSNeMrXk6HRnIYRDLEsqfaC1bWvdelR4ofy9c4pDiVeVKPoWpYyw7rO/9vzFlbC2rjd5vr 7qLRC5tj1GhMbOr4ibfO6XNY2rrv1+TCHcsQcGG6YcWOJkTzI76D8Ow3XDvNl4Ck1lsfh7 6vojGudvmY96/4XA4fYEbAU5nUFlDhMK5WppFRbUSHT07DiticbY6LxfSaM23g== To: ecs@d2evs.net, noam@pixelhero.dev, safinaskar@gmail.com, ~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:46 -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