From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <501D12A1.1060906@yahoo.fr> Date: Sat, 4 Aug 2012 14:16:33 +0200 From: Nicolas Bercher User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24) Gecko/20111120 Icedove/3.1.16 MIME-Version: 1.0 To: 9fans@9fans.net References: <20120803171847.GA2720@polynum.com> In-Reply-To: <20120803171847.GA2720@polynum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Cc: vincent douzal Subject: Re: [9fans] Multi-dimensional filesystem Topicbox-Message-UUID: a7d89f1e-ead7-11e9-9d60-3106f5b1d025 On 03/08/2012 19:18, tlaronde@polynum.com wrote: > Hello, > > This is mainly a theoretical question. > > While playing with the representation of mathematical definitions as > a file hierarchy (at dot you find a DESC or whatever named file with > the description, and the subdirs are simply more restrictive > instances of the thing; say : collection -> magma -> mono=EFde -> > group etc.), it is soon obvious that a filesystem is a one dimension > thing: you only follow one string. Multiple "parents" at the same > level are not there. > > One could trick partly using hard or soft links. But with always the > same problem: who is dot-dot, in a case where multiple parents are > here? And multiple parents are not, to my knowledge, supported by > kernel filesystem code. Manipulating the namespace is not the same. > > Has someone ever played with the notion of a multidimensional > filesystem, where '/' is the origin, the nodes would be some > representation of (a, b, c,...) (even negatives perhaps), each node > having a name (user defined one by the way), and if a node is, say > (3, 0, 1,...) this means that it is to be found as the third subdir > of the (1, 0, 0,...) path etc., (In this scheme, if there is no link > (no path) from another notion, it is another dimension). > > Just for intellectual curiosity. > > Best, Hi, As far as I understand, it seems you are interested in the idea of views over your files. Something that has been approached as "non-hierarchical file systems". But the complexity of handling such graphs often seems to be the reason why these projects failed. Not to mention how the pain to adapt them to the existing systems that are strictly hierarchical. In a project we presented in iwp9 6e (2011), we introduced the design of a filesystem that stores files (stream or hierarchy of files) in /records/ on a WORM file system (Venti). Records are stored in sequence, as they arrive (in respect to their recording order). Each record is identified by your username 'u', the repository name 'h' (for host) and an index related to time 't' (that is not time, but a self incremented interger linked to the date in the current calendar). Each triplet {u,h,t} is uniquely linked to a Venti SHA-1 score. That is the ground lev= el. On top of that, you are free to point files to build any view on them and store these views again in new records, using any naming convention you like at this moment. A non intrusive hypertext language can be used to write a log book from were you point the files you stored in records. From this log book, you can do literate programming, run scripts on files, etc. (For the moment, Emacs org-mode seems to be a good hyper-text language to start from.) A third component, a "triplet" indexer, helps you to find which records points to other records, an vice versa. A plain text search engine helps you to retrieve text from the past. All is centered on traceability= . We spent a lot of time studying reference bibliography from the 60s to today and already have plans for implementation of the ground level file system on top of Venti. Hope this will interest you, at least "just for intellectual curiosity"! ;-) Nicolas