Date: 7 Jun 1996 11:50:39 +0200 From: "Stefan Bethke" <stefan@Promo.DE> To: "Terry Lambert" <terry@lambert.org> Cc: hackers@FreeBSD.ORG Subject: Re: Breaking ffs - speed en Message-ID: <n1377974155.17960@quick.Promo.DE>
index | next in thread | raw e-mail
> You want wierd: I want a logical numeric name space for files so that > the number is hooked to function and invariant under renaming. > This would let me rename /etc/passwd to a Spanish or Japanese name > (for instance) and still let /bin/login and everything that references > the file by number chain continue to function normally. Then I > want name catalogs for every language. > > Now *that's* wierd. 8-) 8-). This somewhat the same the Mac HFS works. While it doesn't provide concurrent different name spaces, each file on a HFS volume has a distict ID, which is never reused. This way, a user can rename and move files on the same volume anyway s/he likes; any program referencing a file (i. e. a placed image in a DTP application) will find the file regardless. Mac "aliases" (which essentially serve the same purpose as symlinks) also work this way. The Mac uses only two functional ids: 2 always is the volume root directory, and 1 (I think) is the active "System Folder". Having a comparable mechanism in a FreeBSD file system would allow Mac file servers (such as the one included in the netatalk package) to serve the files correctly; currently, the file server simulates the ids, so after unmounting and remounting the server volume, file referenced by id won't be found anymore. So what are file names good for? Currently, the serve two purposes: to uniquely identify the file for a program that needs to access that file, and for a user to tell files apart. For any program, any type of reference (like a number) will work; for a user, an alphanumeric, symbolic name best identifies a particular file. However, why shouldn't I be able to call /etc/passwd "Local User+Password Database", because I can remember better for what the file is good? Of course, working in a shell, I still would prefer "passwd". Seperating references for programs and humans also would allow something I wanted to have for quite some time: consider a typical daemon package, consisting of some binaries, some configuration files and some data files that are worked upon: currenty, one has to decide whether to integrate that into the filesystem standard (etc/, libexec/ /var/...), or to create a seperate directory for each package (/usr/local/package). Both views are equally useful: sometimes, I'd like to work on several configuration files for different, interrelated packages; sometimes, I'm considered what files at all are belonging to a certain package at all. So the solution would be to represent the files in a net rather than in a tree, allowing for several views on the filesystem. Again, working in a shell, this might be confusing and complicated, so I'd rather stick with the current model. And, yes, I could simulate this with gobs of symlinks; but that awkward. Stefan Bethke -- Promo Datentechnik | Tel. +49-40-431360-0 + Systemberatung GmbH | Fax. +49-40-431360-60 Waterloohain 6-8 | e-mail: stefan@Promo.DE D-22769 Hamburg | http://www.Promo.DE/help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?n1377974155.17960>