From mboxrd@z Thu Jan 1 00:00:00 1970 To: 9fans@cse.psu.edu Subject: [9fans] rewriting paths [was: mv vs cp] In-Reply-To: <20011007162401.77DEE1998A@mail.cse.psu.edu> References: <20011007162401.77DEE1998A@mail.cse.psu.edu> From: Richard Uhtenwoldt Message-Id: Date: Mon, 8 Oct 2001 10:43:04 -0700 Topicbox-Message-UUID: 021f546c-eaca-11e9-9e20-41e7f4b1d025 I was thinking about this in the bathtub just now. One could interpose a filesystem between the user and kfs --or wherever one's files are really stored-- called renamefs, which rewrites paths before forwarding them to kfs. 9P requests do not really contain paths, but you get the idea: the new file server, renamefs, maintains a rewrite table containing the paths specified by past move commands (2 paths per move command to be precise). This state is used to rewrite certain 9P requests (eg, some walk requests) before relaying them to the server that really stores files. To increase the usefulness of renamefs, we allow it to store 2 types of records. Specifically, a record can take the form D , which means that the string "no longer lives here" (ie, renamefs will act as if does not exist), or it can take the form A , which means that will get rewritten as and does not carry the implication that no longer lives here. (Yes, yes, I know: between and you need some lexeme that does not occur in paths.) Then, Mv can be implemented by adding two records, A and D, and something resembling Unix's Ln -s is implementable by adding one record, A, to the rewrite table inside renamefs. The main socioeconomic purpose of these features is to make Unix users feel more at home by providing means to move directories, means to do inter-directory moves and symlinks. Moreover, Del which just adds D to the rewrite table, is a delete that supports undelete (via removal of the D record). And resource forks can be implemented via ... --Just kidding. No need to modify 9P of course: just have renamefs listen on a specific file like /foo/rename where foo might be mnt (sorry for my unfamiliarity with Plan9 file naming conventions) and have mv write requests (candidates already in the form of strings for entry into the rewrite table) to /foo/rename (rather than having mv send rename or copy and delete requests like it does now). When everyone is sleeping, or when the user says so, renamefs can empty the rewrite table by actually copying and deleting files in the underlying filesystem. Call this operation "update". There are multiple ways I'm sure to create pathological situations with renamefs, and I do not know enough about Plan 9 to address them, except to point out that one way to recover from pathology --assuming the update operation has not run yet-- is simply to delete the rewrite table via, eg, echo clear >>/foo/rename or, if the namespace is so screwed up that that impossible, to reboot without mounting renamefs. Advantages of my design: Users who do not need the functionality do not pay any cost: the code for renamefs and it's clients (eg, the new mv command) lie dormant on the hard drive where they cannot cause problems. No modification of extant code is required. Makes Plan 9 look more like Unix for those who want want that sort of thing, and yes I hear loud and clear that many here do not.