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>
next in thread | raw e-mail | index | archive | help
> 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/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?n1377974155.17960>