Re: File as a directory - VFS Changes
Hi; Why is this discussion revoling around Relational Databases. The attributes of the files and files themselves, if were to be modelled for querying a Realtional Database would really s**k. The attribute info is neither structured, nor is it unstructured, its SEMI-STRUCTURED. Exceuting Structured Query Lang(Sql) over semistrutured data would result in -> Harder modelling (almost a waste of effort), -> Complex Quering (Eleganant system of no use because of the amout of joins that would result in Quering , if you somehow model semi-structured data in some structured Data Model); The best option, to start would be with best COT. I feel we should look at Loreal a stanford project. For hints about modelling our "whatever". Regards Faraz :) - Original Message - From: "Nikita Danilov" <[EMAIL PROTECTED]> To: "Jonathan Briggs" <[EMAIL PROTECTED]> Cc: "Hans Reiser" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; "Alexander G. M. Smith" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; ; <[EMAIL PROTECTED]>; "Nate Diller" <[EMAIL PROTECTED]> Sent: Thursday, June 02, 2005 4:54 PM Subject: Re: File as a directory - VFS Changes > Jonathan Briggs writes: > > On Thu, 2005-06-02 at 14:38 +0400, Nikita Danilov wrote: > > > Jonathan Briggs writes: > > > > On Wed, 2005-06-01 at 21:27 +0400, Nikita Danilov wrote: > > > > [snip] > > > > > Frankly speaking, I suspect that name-as-attribute is going to limit > > > > > usability of file system significantly. > > > > Usability as in features? Or usability as in performance? > > Usability as in ease of use. > > [...] > > > > > A index is an arrangement of information about the indexed items. The > > index contents *belong* to the items. An index by name? That name > > belongs to the item. An index by date? Those dates are properties of > > In the flat world of relation databases, maybe. But almost nowhere else > improper name is an attribute of its signified: variable is not an > attribute of object it points to, URL is not an attribute of the web > page, block number is not an attribute of data stored in that block on > the disk, etc. > > [...] > > > > > In the same way that you can descend a directory tree and copy the names > > found into each item, you can check each item and copy the names found > > into a directory tree. > > Except that as was already discussed resulting directory tree is _bound_ > to be inconsistent with "real names". > > > > > > > > > Indices cannot be reduced to real names (as rename is impossible to > > > implement efficiently), but real names can very well be reduced to > > > indices as exemplified by each and every UNIX file system out there. > > > > > > So, the question is: what real names buy one, that indices do not? > > > > By storing the names in the items, cycles become solvable because you > > can always look at the current directory's name(s) to see where you > > really are. Every name becomes absolutely connected to the top of the > > namespace instead of depending on a parent pointer that may not ever > > connect to the top. > > But cycles are "solvable" in current file systems too: they simply do > not exist there. > > > > > If speeding up rename was very important, you can replace every pathname > > component with a indirect reference instead of using simple strings. > > Changing directory levels is still difficult. > > It is not only speed that will be extremely hard to achieve in that > design; atomicity (in the face of possible crash during rename), and > concurrency control look problematic too. > > > > > -- > > Jonathan Briggs <[EMAIL PROTECTED]> > > eSoft, Inc. > > Nikita. >
RE: File as a directory - VFS Changes
Hi Nikita; The problems of files not fitting in the query of the smart folder is a serious one. We had implemented this same thing for our semantic filesystem. For ex we create a MP3 file is a JPEG folder things it wont ever get listed. This will fundamentally change the way users see your filesytem, the users expect to see the files in the folder they created. This it self should be a default search criteria. We almost solved this by having the "parentdirectory" as a attribute of the file. All the smart folders have thier query transparently modified as "where type=jpg Or parentdirectory=thisdirectory". This make the virtual folder stuff work as EXTENSION to standard file/directory relationship rather than work as RELPLACEMENT. Personal experience says that user dont digest any change to UNIX filesystem mode. Anything extra is OK but replacements are BAD. Think of it you created a C file in a virtual folder for "h" files the files wont get listed(althoug they will exist). THEN WHAT??? the user has to search it BAD, your whole fancy virtual directory USECASE itself is lost and eventually we endup solving nothing. Other issues include this display name stuff etc. They are bad. what if two files with same display name get listed in the same virtual directory. No point in creating a problem and then solving it. Good Work though we dont want to get booged down once WinFS is released. Regards Faraz.
ReConfigurable Directory Structure & Agrregation of files according to semantic.
Hi EveryBody; Iam an final year engneering student and as part of our final year project we have implemented a filesysten which support more than 1 Directory Structures for the same set of files. Each Directory Structure is a XML file discribing the directory structure as well as the attributes of the Files to be listed under Each directory. The file system the mounts this XML file & produces the directory listing by querying the FS for files which match the criteria. The Project will soon be made public under GPL. Following is the abstract. Please guide me with your valuable suggestions. //== 1. Idea of our project: //== The aim of this project is to implement a solution that provides file-level host-based virtualization that provides for better aggregation of content/information based on semantics and properties. File-system organization today very closely mirrors storage paradigms rather than user-access paradigms and semantic grouping. All file-system hierarchies are containers that are expressed based on their physical presence (a separate drive letter on Windows, or a particular mount point based on the volume in Unix). We wish to implement a solution that will allow users to organize their files based on their convenience. We define this convenience in the following forms: The ability to organize the namespace based on certain attribute properties (file-system metadata virtualization). Ex Directory Listing as an output of high level relational query based on file attributes. The ability to de-link position of a file in the hierarchy from its actual storage (file metadata virtualization) Ex Directory Listing as an output of high level relational query based on file attributes. The ability to de-link position of a file in the hierarchy from its actual storage (file metadata virtualization) Ex Automatically Listing the files with the proper attributes in the respective directories. Create & forget file system now puts your MP3 file in the right folder no matter where they are stored on the disk. The ability to create and manipulate namespaces using well-known metaphors (XML schema descriptions and schema editors) Ex. Define the directory structure with directory query as an XML file. Mount multiple such directory structures (virtualization). There by allowing multiple organizational views for the same set of files. The ability to continue using the standard metaphors for manipulation and access to information (file-system kernel APIs), thus maintaining current large body of applications unbroken) . Ex. Make all this features available as an standard file system so existing apps wont fail __ Do you Yahoo!? Yahoo! Mail - More reliable, more storage, less spam http://mail.yahoo.com
