Message-ID: <F85D67DA3ED8620FCA58EF75529278B9@pixelhero.dev>
To: 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:31:25 -0500
From: noam@pixelhero.dev
In-Reply-To: <CAPnZJGBejeA+9APimVY6+HH=fWZJfW=QXJaOEK-JhhESRP+cSg@mail.gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=utf-8

Quoth Askar Safin <safinaskar@gmail.com>:
> Hi. This letter is mostly not for Drew himself, but for everybody
> else. I hope that Drew's readers will read this mail and will know how
> bad Plan 9 actually is.

I use Plan 9 as my primary personal operating system, and am writing this within it.

> As you can see by carefully reading this source, "mv" always
> unconditionally COPIES file data (as opposed to Linux: Linux and all
> sane OS move files without copying when on the same file system)!

> As well as I remember I got this answer: this is because the 9P
> protocol (core file protocol in Plan 9) doesn't have move operation.

The wstat operation, used to update metadata, can be (and is, in fact, *in the code YOU LINKED*) used as a rename operation.

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.

The reality is that it's doable, but nobody has cared enough to make the needed changes, because it _hasn't mattered_. Yes, it's slower - but how often do you move a lot of data to another point on the *same file system*?


- Noam Preil