Thread: [Relfs-devel] New RelFS prototype, with query ability - and binary release
Status: Pre-Alpha
Brought to you by:
applejack
Menu
▾
▴
relfs-devel
|
From: Vincenzo C. <vin...@ya...> - 2005-10-04 00:51:46
|
Many, many things have changed since the last relfs prototype! I didn't want to annunce anything until I'd have the time to solve the tons of problems I had both with ocamlfuse and relfs. Now that I have reached a stable development state, here I am - asking again for request for enhancements, and advice for use cases you would like to work in relfs. It's so rare to have a developer asking for "requests" that you can't miss this great chance! Talk to us about your user data indexing problems! The new prototype is available in binary flavour for Debian Sarge and Fedora Core 4 on the sf.net download page, or in source form in CVS as usual. NEWS 1. Directories representing queries now work The most important feature is that RelFS is now able to host sql queries as if they were directories: First of all, we copy some file into our mountpoint: $ cp *.ml relfs_dir/ Now we can list these files: $ ls relfs_dir/ Connection.ml Files.ml Indexes.ml Index.ml RelFS.ml Schema.ml Util.ml UUID.ml Now we can query the database for all files starting with a "C" (note that "%%" will be replaced with "/"): $ ls "relfs_dir/#select id,'%%'||name as path from obj where name like 'C%'" Connection.ml We can even "cd" inside such a directory (or better symlink it): $ cd "relfs_dir/#select id,'%%'||name as path from obj where name like 'I%'" $ ls -la drwxr-xr-x 1 vincenzo vincenzo 4096 2005-10-04 02:33 . drwxr-xr-x 2 vincenzo vincenzo 4096 2005-10-04 02:33 .. -rw-r--r-- 1 vincenzo vincenzo 4662 2005-10-04 02:33 Indexes.ml -rw-r--r-- 1 vincenzo vincenzo 3993 2005-10-04 02:33 Index.ml Of course, results are updated for each readdir, and files are like hardlinks to original ones, so if you edit Index.ml changes will be reflected in the original file. 2. Switch to the OCaml programming language is complete and there are binary releases The OCaml programming language is being used - and this resulted in really robust code (except where I know that it's not robust ;) ). This required implementing glue code to bind fuse functions to OCaml - this was done, and took a very long time to be done correctly, mostly due to problems interrupting the OCaml runtime from within multiple C threads. These problems are now solved, and there is a project named "ocamlfuse" on sourceforge, which is proving a very good solution to implement stable and maintenable userland filesystems. I released only binary files, one for FC4 and one for Sarge. To compile from source you have to use the CVS version, and I don't have any other distro handy to produce other binary releases. It's just to help planning features, not to distribute something that is of no use for the great public :) 3. Codebase has been cleaned up After having rewritten RelFS in OCaml, I realized I had many problems both with implementing correct unix semantics, and with caching metadata lookups from the database. So I reworked my code line by line, and in its current form it's very robust and fast, but there's no caching at all :) (yes, I had to make a choice). 4. What?? Is it complete? No, of course. For example, the queries "pathof" and "lookup" are really slow. This is because relational databases and trees don't agree. I will have to solve this - maybe just using materialized paths and who cares about renames :) Also, I will provide a definitive interface for plugins, and then I will have to write some good indexer. All filesystem metadata (e.g. results from stat) should be in the database. Extended attributes should be used and will be used as a communication interface with the database - e.g. tags from mp3s. A simple query (and query refinement) interface must be written in a hurry. 5. It feels so undocumented! Of course, I will answer to any question and document FAQs. It's experimental as usual. Bye and have fun Vincenzo Ciancia ___________________________________ Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB http://mail.yahoo.it |
|
From: Jasper v. de G. <th....@hc...> - 2005-10-06 14:32:00
|
Vincenzo Ciancia wrote: > Many, many things have changed since the last relfs prototype! > > I didn't want to annunce anything until I'd have the time to solve the > tons of problems I had both with ocamlfuse and relfs. Now that I have > reached a stable development state, here I am - asking again for > request for enhancements, and advice for use cases you would like to > work in relfs. > > It's so rare to have a developer asking for "requests" that you can't miss > this great chance! Talk to us about your user data indexing problems! I've been exploring some ideas similar to relfs lately and one of the most obnoxious problems I haven't been able to get around is what to do with identical filenames in one directory. Traditionally this simply isn't allowed, which is workable because it's very clear what other files are in the directory. As soon as you introduce some kind of query-like directories this becomes a nightmare though, as it's hardly realistic to force people to use completely unique names for each file and dynamically renaming files is also less than ideal. Of course this can be solved by creating some new unique attribute which programs can use, but old programs won't know how to. And if you turn it around (use some unique id for the actual filename and expose the non-unique "filename" as some new attribute), which I would probably prefer, old programs will work but will probably look quite ugly (although it would be possible to make sure that the unique id looks as much like the "filename" as possible). In short, I can think of some solutions, but none of them seem perfect and I was wondering what other people's thoughts on this were. |
|
From: Vincenzo C. <vin...@ya...> - 2005-10-12 23:09:04
|
Alle Thursday 06 October 2005 10:31, Jasper van de Gronde ha scritto: > In short, I can think of some solutions, but none of them seem perfect > and I was wondering what other people's thoughts on this were. Yes, this may be one of the biggest concerns for relfs. By now non-unique paths in queries behave in a "just wrong" fashion: relfs performs a "select distinct ..." on the query result set. Queries are not the only place where multpile files per path can be found: there is the "trash" folder for example (and see how old versions of kde handle this, it was "just wrong" too). Now kde has a "trash:" protocol that allows duplicate file names, but there is no way for an user to know where, for example, a deleted file was before the unlink, you just have two "equal" files that you can open and examine. Windows does the same. Also tar and zip archives can have duplicated path entries because one added a new version of a certain file. And the worst problem is that case by case a distinguishing attribute (e.g. the original path in case of trash, or the addition time in case of archives) must be selected. In this uncomfortable situation, I think that the easiest way to avoid breaking abstraction is to just disambiguate names adding some other attribute - e.g. suppose I select both /home/vincenzo/projects/ocamlfuse/src/README and /home/vincenzo/projects/thesis/src/README whe should show README [thesis] README [ocamlfuse] where "thesis" and "ocamlfuse" are the first directory which differs in the path. Of course, there is the problem that "PATH_MAX" gets shortened and one will eventually need to shorten files a-la-vfat-on-8.3, say VeryLongFilename......~1[veryLongDirectory...Name] This looks like a good heuristic, because the upper you go in the directory tree, the more probable it is that you choose a meaningful word to the user. Yes, this looks like trial and error. For example an user could prefer to see README [phd] and README [free software] because he has added ad-hoc extended attributes to classify certain subtrees. Maybe we could provide easy-to-use disambiguation mechanisms. However this goes far beyond the philosophy of "keeping it simple": what I would expect in the future is that extended attributes, which are a great possibility effectively unused in current filesystems, and that in relfs and I think many other similar projects will be extensively used, will be soon or later smoothly integrated in file managers and file open dialogs of applications. At this points, seeing README [directory_that_I_never_saw_before] will not be such a big problem, because there will be a small "preview" panel on the side of a file open dialog or of the file manager window showing all other extended attributes and helping the user in the task of identifying files that have the same name in the same query. Do you find this convincing? |
|
From: Vincenzo C. <vin...@ya...> - 2005-10-08 10:15:22
|
[apologizes for multiple copies, my mail-server seems to have forgotten my previous reply but could eventually change its mind] Alle Thursday 06 October 2005 10:31, Jasper van de Gronde ha scritto: > In short, I can think of some solutions, but none of them seem perfect > and I was wondering what other people's thoughts on this were. Yes, this may be one of the biggest concerns for relfs. By now non-unique paths in queries behave in a "just wrong" fashion: relfs performs a "select distinct ..." on the query result set. Queries are not the only place where multpile files per path can be found: there is the "trash" folder for example (and see how old versions of kde handle this, it was "just wrong" too). Now kde has a "trash:" protocol that allows duplicate file names, but there is no way for an user to know where, for example, a deleted file was before the unlink, you just have two "equal" files that you can open and examine. Windows does the same. Also tar and zip archives can have duplicated path entries because one added a new version of a certain file. And the worst problem is that case by case a distinguishing attribute (e.g. the original path in case of trash, or the addition time in case of archives) must be selected. In this uncomfortable situation, I think that the easiest way to avoid breaking abstraction is to just disambiguate names adding some other attribute - e.g. suppose I select both /home/vincenzo/projects/ocamlfuse/src/README and /home/vincenzo/projects/thesis/src/README whe should show README [thesis] README [ocamlfuse] where "thesis" and "ocamlfuse" are the first directory which differs in the path. Of course, there is the problem that "PATH_MAX" gets shortened and one will eventually need to shorten files a-la-vfat-on-8.3, say VeryLongFilename......~1[veryLongDirectory...Name] This looks like a good heuristic, because the upper you go in the directory tree, the more probable it is that you choose a meaningful word to the user. Yes, this looks like trial and error. For example an user could prefer to see README [phd] and README [free software] because he has added ad-hoc extended attributes to classify certain subtrees. Maybe we could provide easy-to-use disambiguation mechanisms. However this goes far beyond the philosophy of "keeping it simple": what I would expect in the future is that extended attributes, which are a great possibility effectively unused in current filesystems, and that in relfs and I think many other similar projects will be extensively used, will be soon or later smoothly integrated in file managers and file open dialogs of applications. At this points, seeing README [directory_that_I_never_saw_before] will not be such a big problem, because there will be a small "preview" panel on the side of a file open dialog or of the file manager window showing all other extended attributes and helping the user in the task of identifying files that have the same name in the same query. Do you find this convincing? Bye Vincenzo |
|
From: Jasper v. de G. <th....@hc...> - 2005-10-08 10:52:14
|
Vincenzo Ciancia wrote: > ... > Queries are not the only place where multpile files per path can be found: > there is the "trash" folder for example (and see how old versions of kde > handle this, it was "just wrong" too). Now kde has a "trash:" protocol that > allows duplicate file names, but there is no way for an user to know where, > for example, a deleted file was before the unlink, you just have two "equal" > files that you can open and examine. Windows does the same. Also tar and zip > archives can have duplicated path entries because one added a new version of > a certain file. This is a good point, as I hardly ever use the trash bin (or something similar) I hadn't even thought of that. I just checked and Windows basically makes the trash and search results only available through it's explorer interface (which uses a special identifier internally, which can be transformed into a path when a file is opened for example). Of course this wouldn't really be an option for something like relfs (as it works on a lower level). > And the worst problem is that case by case a distinguishing attribute (e.g. > the original path in case of trash, or the addition time in case of archives) > must be selected. In this uncomfortable situation, I think that the easiest > way to avoid breaking abstraction is to just disambiguate names adding some > other attribute - e.g. suppose I select both > > /home/vincenzo/projects/ocamlfuse/src/README > > and > > /home/vincenzo/projects/thesis/src/README > > whe should show > > README [thesis] > README [ocamlfuse] Do you mean as a filename? So a user would use something like cat "README [thesis]" to view the file (on the console)? If so, it might not be too bad. > ... > This looks like a good heuristic, because the upper you go in the directory > tree, the more probable it is that you choose a meaningful word to the user. Especially since people are used to directories. > ... > because he has added ad-hoc extended attributes to classify certain subtrees. > Maybe we could provide easy-to-use disambiguation mechanisms. However this > goes far beyond the philosophy of "keeping it simple": For me the most important aspects of a disambiguation scheme are that it's not too hard to understand for users, predictable and preferrably reasonably stable. The above mentioned scheme should be relatively easy to understand, might be predictable enough (it might get a little complicated when more than two files are involved) and is at least more stable than dynamically assigning sequence numbers or something similar. > what I would expect in > the future is that extended attributes, which are a great possibility > effectively unused in current filesystems, and that in relfs and I think many > other similar projects will be extensively used, will be soon or later > smoothly integrated in file managers and file open dialogs of applications. That would indeed make life easier. Fortunately there is increasing interest in these sorts of things, so who knows. > ... > Do you find this convincing? It's net yet "perfect", but it's definately an interesting option. |
|
From: <rel...@li...> - 2005-12-14 20:09:36
|
Hi Vincenzo et al, As far as I can see the only way round this is to use the physical part of the disk as the id of the file, and the very long name as the human readable format that a user chooses. So it means going to down to disk level to find out a unique identifier, like cylinders and heads and sectors, or even disk address! although there is the problem of transferring between disks, which would mean relfs depending on the human readable format maybe maybe not, as transfering it would take the first available numbers of an id that is not an address but an incremental number that relfs would recognise as such, it being not on the same disk as the operating system, but transferring to a disk would have to be different. Does this give any light to the obnoxious problem of: ->"get(ting) around what to do with identical filenames in one directory." Hal -- -- No Spam solicited, from you or by you, Thanks. -- ---Virus checked by sender - There are no viruses attached to this email.--- ---Although recipients are advised to apply their own virus check to this--- ---message and all their incoming e-mail on delivery. Need any help? Ask.--- |
|
From: Vincenzo C. <vin...@ya...> - 2005-12-16 11:52:23
|
Alle Wednesday 14 December 2005 23:13, rel...@li... ha scritto: > Hi Vincenzo et al, > > As far as I can see the only way round this is to use the physical part of > the disk as the id of the file, and the very long name as the human > readable format that a user chooses. > So it means going to down to disk level to find out a unique identifier, > like cylinders and heads and sectors, or even disk address! > although there is the problem of transferring between disks, which would > mean relfs depending on the human readable format maybe maybe not, as > transfering it would take the first available numbers of an id that is not > an address but an incremental number that relfs would recognise as such, it > being not on the same disk as the operating system, but transferring to a > disk would have to be different. > Does this give any light to the obnoxious problem of: > > ->"get(ting) around what to do with identical filenames in one directory." > > Hal Well, I am convinced that - once that a file has gotten an unique id some way, it can be exposed as an extended attribute, so smart user programs will be able to differentiate files as now is done in kde with the "trash:" protocol and in any e-mail client when showing different e-mail messages but with the same visible fields. 1. obtaining ids In the long run I think that the best way to obtain ids from files would be to use an incremental hashing algorithm, i.e. one that can rehash a file just by rehashing a block (if such an algorithm can be robust, I don't know). For example one could use an md5 for each block, and then md5 the resulting list. This way hashing can be "efficient" at least in principle. Another mentioned possibility was to use UUIDs but I would prefer hashes because they can be used to distribute the filesystem over a network (even existing peer-to-peer networks) and they persist when moving files. For now, ids will keep on being just integers obtained from a psql sequence 2. presenting files to "non-smart" applications What should we show in "ls" when there are two files? I think we already decided to adopt a quick-and-dirty strategy (which I should have implemented three weeks ago, however it will come "soon" :)) and then wait for requst for enhancements. Do you like this all or would you prefer another solution? Vincenzo |
|
From: Jasper v. de G. <th....@hc...> - 2005-12-16 16:22:52
|
Vincenzo Ciancia wrote: > ... > > Do you like this all or would you prefer another solution? I think you summarized the discussion so far reasonably well. |
|
From: <rel...@li...> - 2005-11-19 10:43:00
|
On Saturday 08 Oct 2005 05:39, Vincenzo Ciancia said to us all: Its confusing to have filenames which are the same in the same directory, and may cause complications. This can be resolved with the address attribute of the harddisc address, which resolves adding extra junk into the table or database. Queries would not need an extra redundant name. When I deleted an ntfs partition, and made several ext3 partitions by mistake overhastily, I then tried to get them back, and used several tools, both windows and linux. A number of ways that they were portrayed gave me scope to see where they were, even though they had the same names, as the tools put all the files into numbered directories instead of in their original dirs which had been lost. This real life scenario helped me to unformat certain blocks and clusters, so I had to check their real addresses in order to bring what I could back. Am I of any help? Hal ->"Alle Thursday 06 October 2005 10:31, Jasper van de Gronde ha scritto: ->"> In short, I can think of some solutions, but none of them seem perfect ->"> and I was wondering what other people's thoughts on this were. ->" ->"Yes, this may be one of the biggest concerns for relfs. By now non-unique ->"paths in queries behave in a "just wrong" fashion: relfs performs a "select ->"distinct ..." on the query result set. ->" ->"Queries are not the only place where multpile files per path can be found: ->"there is the "trash" folder for example (and see how old versions of kde ->"handle this, it was "just wrong" too). Now kde has a "trash:" protocol that ->"allows duplicate file names, but there is no way for an user to know where, ->"for example, a deleted file was before the unlink, you just have two "equal" ->"files that you can open and examine. Windows does the same. Also tar and zip ->"archives can have duplicated path entries because one added a new version of ->"a certain file. ->" ->"And the worst problem is that case by case a distinguishing attribute (e.g. ->"the original path in case of trash, or the addition time in case of archives) ->"must be selected. In this uncomfortable situation, I think that the easiest ->"way to avoid breaking abstraction is to just disambiguate names adding some ->"other attribute - e.g. suppose I select both ->" ->"/home/vincenzo/projects/ocamlfuse/src/README ->" ->"and ->" ->"/home/vincenzo/projects/thesis/src/README ->" ->"whe should show ->" ->"README [thesis] ->"README [ocamlfuse] ->" ->"where "thesis" and "ocamlfuse" are the first directory which differs in the ->"path. Of course, there is the problem that "PATH_MAX" gets shortened and one ->"will eventually need to shorten files a-la-vfat-on-8.3, say ->" ->"VeryLongFilename......~1[veryLongDirectory...Name] ->" ->"This looks like a good heuristic, because the upper you go in the directory ->"tree, the more probable it is that you choose a meaningful word to the user. ->" ->"Yes, this looks like trial and error. For example an user could prefer to see ->" ->"README [phd] ->" ->"and ->" ->"README [free software] ->" ->"because he has added ad-hoc extended attributes to classify certain subtrees. ->"Maybe we could provide easy-to-use disambiguation mechanisms. However this ->"goes far beyond the philosophy of "keeping it simple": what I would expect in ->"the future is that extended attributes, which are a great possibility ->"effectively unused in current filesystems, and that in relfs and I think many ->"other similar projects will be extensively used, will be soon or later ->"smoothly integrated in file managers and file open dialogs of applications. ->" ->"At this points, seeing README [directory_that_I_never_saw_before] will not be ->"such a big problem, because there will be a small "preview" panel on the side ->"of a file open dialog or of the file manager window showing all other ->"extended attributes and helping the user in the task of identifying files ->"that have the same name in the same query. ->" ->"Do you find this convincing? ->" ->" ->" ->"------------------------------------------------------- ->"This SF.Net email is sponsored by: ->"Power Architecture Resource Center: Free content, downloads, discussions, ->"and more. http://solutions.newsforge.com/ibmarch.tmpl ->"_______________________________________________ ->"Relfs-devel mailing list ->"Rel...@li... ->"https://lists.sourceforge.net/lists/listinfo/relfs-devel ->" ->" ->" -- The information contained in this email message may be confidential. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the we monitor e-mails sent and received. Further communication will signify your consent to this. Thank you. More information can be found at http://www.fasterbytes.net |
|
From: Vincenzo C. <vin...@ya...> - 2005-11-19 15:05:24
|
> On Saturday 08 Oct 2005 05:39, Vincenzo Ciancia said to us all: > > Its confusing to have filenames which are the same in the same directory, Did I really say that? :) > and may cause complications. This can be resolved with the address > attribute of the harddisc address, which resolves adding extra junk into > the table or database. Queries would not need an extra redundant name. Before all: the problem is that, when you perform a query, you can get as a= =20 result two different files, which are physically stored in two different=20 directories, but have the same name and should be shown in the same=20 "resulting" directory by the query. RelFS distinguishes these files by their unique ID (which you can think of = as=20 being the same thing as the inode number - which I think you are calling th= e=20 "harddisk address" present in ordinary filesystems) until it presents them = to=20 the user. =46rom then on, there is no way to tell which file the user asked for - so = this=20 is only a problem in the presentation layer - we should present files in su= ch=20 a way that the user can tell us back exactly what file he/she wants. So, if I understand you correctly, you propose to add the "inode number" as= a=20 part of the primary key for the table of all files in the database, but the= =20 database should not be affected by this problem, since we already have an=20 unique id, the only problem is not presenting the user an "anonymous" uniqu= e=20 id but something more meaningful. Of course we could eventually use the=20 unique id in case we can't find anything better. This weekend I will try to finish to implement the disambiguation scheme=20 proposed in this thread - but if you feel like I missed something in your=20 e-mail let us know. thanks and bye Vincenzo PS:=20 > Do not use, copy or disclose the information in any way nor act in > reliance on it and notify the sender immediately. Ahem... this information has already been disclosed :) Could you please ask= =20 who puts this banner on your e-mails to avoid doing that for this list?=20 |
|
From: Jasper v. de G. <th....@hc...> - 2005-11-20 11:15:34
|
rel...@li... wrote: > On Saturday 08 Oct 2005 05:39, Vincenzo Ciancia said to us all: > > Its confusing to have filenames which are the same in the same directory, and > may cause complications. This can be resolved with the address attribute of > the harddisc address, which resolves adding extra junk into the table or > database. Queries would not need an extra redundant name. > When I deleted an ntfs partition, and made several ext3 partitions by mistake > overhastily, I then tried to get them back, and used several tools, both > windows and linux. A number of ways that they were portrayed gave me scope to > see where they were, even though they had the same names, as the tools put > all the files into numbered directories instead of in their original dirs > which had been lost. This real life scenario helped me to unformat certain > blocks and clusters, so I had to check their real addresses in order to bring > what I could back. Am I of any help? > Hal It is indeed a reasonable solution, but it is does have some drawbacks: - It only serves to distinguish files, it doesn't tell the user anything about what file it is. - It might change unexpectedly if the files are reordered (which is not uncommon, although perhaps uncommon enough to cause not too many problems). I can live with the first one, and the second could be worked around by not using an actual blocknumber but some kind of artificial index. Apart from these minor drawbacks, however, it also doesn't solve the problem of saving/renaming files (you obviously don't want people to enter these numbers, yet it should be possible to overwrite files for example, as well as to create new files). I'd be interested in any ideas you (or others) may have on the subject though (might not be entirely on-topic, but the mailinglist doesn't seem to be busy enough for that to be much of a problem). |
|
From: Vincenzo C. <vin...@ya...> - 2005-11-23 00:27:20
|
Alle Sunday 20 November 2005 12:15, Jasper van de Gronde ha scritto: > Apart > from these minor drawbacks, however, it also doesn't solve the problem > of saving/renaming files (you obviously don't want people to enter these > numbers, yet it should be possible to overwrite files for example, as > well as to create new files). I'd be interested in any ideas you (or > others) may have on the subject though (might not be entirely on-topic, > but the mailinglist doesn't seem to be busy enough for that to be much > of a problem). =46rom my point of view, saving and renaming files is not possible in a=20 directory representing a query on the database; query directories are=20 read-only. I don't see any obvious solution for the case where you can=20 create new files in a directory with "disambiguated" file names. V. |
|
From: Jasper v. de G. <th....@hc...> - 2005-11-23 07:41:36
|
Vincenzo Ciancia wrote: > Alle Sunday 20 November 2005 12:15, Jasper van de Gronde ha scritto: >>Apart >>from these minor drawbacks, however, it also doesn't solve the problem >>of saving/renaming files (you obviously don't want people to enter these >>numbers, yet it should be possible to overwrite files for example, as >>well as to create new files). I'd be interested in any ideas you (or >>others) may have on the subject though (might not be entirely on-topic, >>but the mailinglist doesn't seem to be busy enough for that to be much >>of a problem). > > From my point of view, saving and renaming files is not possible in a > directory representing a query on the database; query directories are > read-only. I don't see any obvious solution for the case where you can > create new files in a directory with "disambiguated" file names. That's true (I'm assuming you're talking about the directory being read-only and not necessarily the files in it), and I might indeed be able to get by with that too. |
|
From: Vincenzo C. <vin...@ya...> - 2005-11-23 22:56:39
|
Alle Wednesday 23 November 2005 08:41, Jasper van de Gronde ha scritto: > That's true (I'm assuming you're talking about the directory being > read-only and not necessarily the files in it), and I might indeed be > able to get by with that too. Yes, files are read-write because they belong to their original location. BTW it is already working that way on my laptop, but with disambiguation based on database ids :) Do you have something in mind that I don't see, an use case where writing to directories, somewhat containing duplicate files, might be useful? Here begins a not so useful digression - I was thinking about "why on earth am I designing a database filesystem, which should allow me to get rid of hierarchies, and the first thing I want to do is the hierarchy of all my mp3s, with authors at the first level and albums at the second?" - and here's a summary of my answer: I sometimes think that in a true database filesystem the user should be allowed to add files to "the system" and not to a specific directory. This "system" however must be slightly hierarchical again: you can't avoid to have two different files called README, but you could avoid that locally, for a single project or "group of files". This would be a single level hierarchy. But (thanks for the following remark go to a "local anonymous referee" who I suppose is ignoring relfs-devel e-mails in this period :) ) there are projects which include different versions of files in different subdirectories (e.g. translations of documentation), so at least second level of hierarchy would be needed. In general it looks like hierarchy is useful locally, even if for the whole file system it is a mess. In fact, hiearchy allows navigation, which is not possible using only queries, and it is also a lightweight and stable classification mechanism. For example, in relfs source distribution there is the "src" directory, and the (empty, sigh, and in CVS by mistake) "doc" directory. I would be crazy if I thought to distribute the thing without this small hierarchy. But in the large hierarchy sucks, so perhaps in the near future, when database filesystems will be widely used (yes I am trying to be optimistic) a typical usage will be to add "packages" to the "system", each one with a local hierarchy. Of course if there will be multiuser database filesystems, there will be no need for real "/usr/bin", "/usr/lib" and "/usr/doc" directories, even if each "package" will carry these. A shell will just query the database for all binary public files of all packages and the linker will do the same. But - I repeat since this is the point - hierarchy will resist, locally. Vincenzo |
Thanks for helping keep SourceForge clean.
X