relfs-devel — Development mailing list for the relational filesystem project

[Relfs-devel] interesting

[UK Chevron-T. A. <hu...@lo...>]

Hi,
I think you are  interested in that  kind of information,  so probably that article can be helpful, please read it here <http://mariarosaria.crystalclearwindowwashing.org/e7abd/61>

Warmest regards, UK Chevron-Texaco Award

Re: [Relfs-devel] Query-FS - alternative core for RelFS (and more) in Common Lisp

[Michael R. <fb0...@ra...>]

On 09/15/2010 11:35 AM, Michael Raskin wrote:
> 	Does anyone want to try this out? I am ready to help with installation.
> Does anyone think that it is a good foundation for replacing RelFS? Does
> anyone have any suggestion for further changes (what plugins should do,
> what DSL should be etc)? Should this be mentioned on relfs.sf.net?

To show my current progress with queries to anyone interested - the
literal query I currently use for password manager (whitespace slightly
changed). This code is committed to the public monotone repository, so
feel free to ask for help with setting this up.

transient *master-password* ""
setter "::password" *master-password*

for p from
("select username || '@' || service, password from
   passwords
where username is not null and ~a <> ''"
  *master-password*)
encrypted with *master-password* file name (p 1)

dir "by-service"
create-dir name ("insert into passwords (service) values (~a)" name)

with srv from
("select distinct service from passwords where ~a <> ''"
   *master-password*)
create name
  ("insert into passwords (service, username) values (~a, ~a)"
     (srv 0) name)

sink data "::remove::" ""
  ("delete from passwords where service = ~a" (srv 0))

for un from
  ("select username, password from passwords where
      service = ~a and username is not null" (srv 0))
encrypted with *master-password*
  sink-removable data name (un 1)
  ("update passwords set password = ~a where
      username = ~a and service = ~a"
    data name (srv 0))
  ("delete from passwords where
      username = ~a and service = ~a"
    name (srv 0))

[Relfs-devel] Query-FS - alternative core for RelFS (and more) in Common Lisp

[Michael R. <fb0...@ra...>]

		Hello.
	I have updated a ton of things in Query-FS project recently and today I
uploaded a "closed" Query-FS source snapshot + dependencies to
common-lisp.net . See http://mtn-host.prjek.net/projects/cl-fuse/ for
details of installation - you need SBCL and GCC to be installed (and tar
and gzip are hard to avoid on Unix-like systems).
	The idea behind Query-FS is layering, creating DSLs and using Lisp for
DSLs. There are many layers in creating an FS that can run SQL SELECT's
over files. In Query-FS there are two-layered Common Lisp FUSE bindings
(you don't need to understand their inner workings even for developing
Query-FS), management of the non-core code (plugins and queries),
plugins - parsers of DSLs for queries and queries themselves.
	My idea is that large files should not be stored on QueryFS itself,
they should be stored on a dedicated filesystem and QueryFS should just
provide symlinks. I also guess that it is better to have separate
indexers (maybe even using inotify+periodical scrubbing).
	Among other things, there is possibility SQL queries that return
filesystem objects.
	
	Does anyone want to try this out? I am ready to help with installation.
Does anyone think that it is a good foundation for replacing RelFS? Does
anyone have any suggestion for further changes (what plugins should do,
what DSL should be etc)? Should this be mentioned on relfs.sf.net?

	Thanks, good bye
Michael Raskin

Re: [Relfs-devel] Post-OCaml development. CL-FUSE

[Michael R. <fb0...@ra...>]

Vincenzo Ciancia wrote:
>> Currently I write relatively ugly code, namely
>>
>> for n name-position 0 from "select distinct name from indexed_files"
>> dir name
>> for f name-position 0 from
>> (fmt "select id, path from indexed_files where ~a" (clsql:sql [= (first
>> n) [name]]))
>> symlink name (f 1)
>>
>> to create a simple "name -> name bearers" index.
>>
>> How should it be? No need to be a Lisp expert here.. I also think about
>> this now.
>>
> 
> So we are likely used to different idioms and I can't parse the above
> very well. What do you mean with a "name -> name bearers" index? Is
> the above a stateful language, or why are there different lines? And
> what is "passed along" between these lines?

It is a DSL translated to Lisp code. Most of the code is supposed to be
purely functional with lexical scoping, like here.

This returns the list of all registered file names, each of them names a
directory containing symlinks to all the files with such name.

Translation in current syntax:

Run query as stated, iterate over rows of result, put the row in "n"
variable and decide that there is an entry called as the first element
in row.

Each entry is a directory with suggested name, and its contents follows.

To get contents, execute query which can be got by applying format
string with "~a" to mark the place where missing condition should be
substituted from parameters to string denoting SQL for comparison
between first element of "n" and [name] column in default table (named
in from clause). For each row the name of entry should be the first
element of the row.

The entry should be a symlink with suggested name and targeting the path
specified in second element of the row.

(both lists are closed implicitly by EOF)

Re: [Relfs-devel] Post-OCaml development. CL-FUSE

[Vincenzo C. <vin...@gm...>]

> Currently I write relatively ugly code, namely
>
> for n name-position 0 from "select distinct name from indexed_files"
> dir name
> for f name-position 0 from
> (fmt "select id, path from indexed_files where ~a" (clsql:sql [= (first
> n) [name]]))
> symlink name (f 1)
>
> to create a simple "name -> name bearers" index.
>
> How should it be? No need to be a Lisp expert here.. I also think about
> this now.
>

So we are likely used to different idioms and I can't parse the above
very well. What do you mean with a "name -> name bearers" index? Is
the above a stateful language, or why are there different lines? And
what is "passed along" between these lines?

Re: [Relfs-devel] Post-OCaml development. CL-FUSE

[Michael R. <fb0...@ra...>]

Vincenzo Ciancia wrote:
>>        I would be glad to hear comments about syntax, extension ideas etc.
>>
> 
> I will look at it soon, as you know I am no lisp expert. However, can
> you provide a personal judgment on your binding? How complete is it?
> Did you test efficiency? Is it multi-threaded? Does it use multiple
> cores? (the latter would be a killer feature if compared to ocaml).

I make this point in a distinct letter for it not to be lost. It is the
main place where I want comments.

Currently I write relatively ugly code, namely

for n name-position 0 from "select distinct name from indexed_files"
dir name
for f name-position 0 from
(fmt "select id, path from indexed_files where ~a" (clsql:sql [= (first
n) [name]]))
symlink name (f 1)

to create a simple "name -> name bearers" index.

How should it be? No need to be a Lisp expert here.. I also think about
this now.

Re: [Relfs-devel] Post-OCaml development. CL-FUSE

[Michael R. <fb0...@ra...>]

Vincenzo Ciancia wrote:
> To anybody reading, that is, to the "casual reader". This project is
> not "abandoned" by itself. It's just that I don't have ANY time for
> it.

I also do not consider RelFS project abandoned. Ocaml version, though,
seems abandoned on any reasonable criteria (nothing worth reusing, no
activity around it etc.)

I hope to submit a paper about my new Lisp branch..

> Such a design inherently does not play well with centralised databases
> like postgresql. After an analysis done this august, we (more or less
> everyone including Michael) agreed that multiple sqlite files are the
> only feasible way.

I currently focus on query interface to the external, so I still use
postgresql because I think of reusing some data.. But in my design using
multiple SQLite DBs will be simple.

> A proper design document will be created if it becomes clear that the
> manpower is really available, that is, if there is someone who really
> has the time to code.

Probably it will partially be documentation of implementation.

> Dear Michael,
> 
> I am glad to hear from you.

I am also glad to receive a reply from you.

>>        As of now, RelFS written in OCaml can be considered abandoned. We
>> decided to switch to some other design. So, what success do you have?
>
> So as you know, the biggest showstopper of relfs is manpower, followed
> / caused also by the lethargic state of ocamlfuse.

And also by some unfortunate things in its general design. And OCamlFuse
is usable right now, the problem is that it is very hard to add
threading to it or improve its speed.

> I don't think I announced anything that you are spoiling already :) So
> no, nothing happened. 5 people want to develop the core relfs (any
> other can just raise their hands) but I didn't ask anything to them,
> since my work and my travels absorb me too much.

If anyone wanted to develop specifically OCaml version, where are the
emails? Where is anything?

I do not consider RelFS as the whole abandoned - or I wouldn't write my
previous email here.

>> http://mtn-host.prjek.net/viewmtn/cl-fuse/revision/browse/23483c4d94f7756d365626b247f82cdd588828e3/example-queries
>>
>>        I would be glad to hear comments about syntax, extension ideas etc.
>>
> 
> I will look at it soon, as you know I am no lisp expert. However, can

There are example-queries. My main question is about your opinion about
these.

> you provide a personal judgment on your binding? How complete is it?
> Did you test efficiency? Is it multi-threaded? Does it use multiple
> cores? (the latter would be a killer feature if compared to ocaml).

My binding is multi-level. On the lowest level, you can use CFFI library
to define C callbacks (these are Lisp functions written by special rules
- related to the way of argument processing). This level is complete
w.r.t. FUSE 2.7.4 release. Actually, you only need a basic
infrastructure there, and the list of fields - there is nothing to wrap
there, user gets raw FUSE interface as it is. About performance: it
boils down to compiled code implementing raw FUSE callbacks. I see no
reason why it should be noticeably slower than C if written carefully.
But SBCL will require more memory for its runtime..

I also allows to implement call manager. By default everything is
single-threaded, but you can instruct my bindings to spawn threads for
requests.

Next level: Lisp-style wrappers. These allow you to implement basic
reading and writing etc. They are easily extensible, though. They
currently force you to have extra memory copying operations (you are
supposed to return Lisp byte sequences, and it will manage foreign
memory interaction). My idea is that you don't care when you feed large
files only via symlinks.

Next level: prototyping bindings with automatic pathname management.
These are even more incomplete and are somewhat hard to extend without
increasing amount of code user has to write. Of course, there is even
more mandatory overhead.

> To you, but probably not really. Try to develop your idea, I will try
> mine (one day, another day, we don't know). We will always be able to
> exchange non-core code. And for now, if your filesystem works, I will

Actually, I currently plan to consider everything except core queries
non-core code. I.e. you can have inotify-listening daemon that tells
filesystem how to update tables. Trivial indexing is implemented via
writing to a special file on my FS - that process is defined in "user
code" in queries.

> probably use it, so perhaps the next step would be to close this
> project and follow you. For now it is better if we remain both  free
> to experiment with our own ideas.

Of course. I do hope to end up with something to officially merge with
RelFS. My project is already in process of consuming previous CL-FUSE
project, so gathering stones is in order.

I guess what we will have to define is the default DB layout for
widespread kinds of indices.

> When you have a prototype alternative design, let me know on this
> list, I will certainly be happy to take a look.

Well, there is currently just layering of definitions.

Re: [Relfs-devel] Post-OCaml development. CL-FUSE

[Vincenzo C. <vin...@gm...>]

To anybody reading, that is, to the "casual reader". This project is
not "abandoned" by itself. It's just that I don't have ANY time for
it.

In particular, along these years I realised that a proper
implementation of a database-backed filesystem in the sense of relfs
needs a decentralised structure, where there are many "volumes" each
other with its own database. At mount time, the database is loaded and
eventually updated.

This way metadata can stay in sync with the data even on different
machines.  When you connect to a music share (e.g. itunes) are you
happy to immediately see the metadata populating your audio player?
The same should be of your external drives, network drives and so on.

Such a design inherently does not play well with centralised databases
like postgresql. After an analysis done this august, we (more or less
everyone including Michael) agreed that multiple sqlite files are the
only feasible way.

A proper design document will be created if it becomes clear that the
manpower is really available, that is, if there is someone who really
has the time to code.

2009/11/17 Michael Raskin <fb0...@ra...>:
>                Hello, Vincenzo and hello, accidental reader.

Dear Michael,

I am glad to hear from you.

>        As of now, RelFS written in OCaml can be considered abandoned. We
> decided to switch to some other design. So, what success do you have?
>

So as you know, the biggest showstopper of relfs is manpower, followed
/ caused also by the lethargic state of ocamlfuse.

I don't think I announced anything that you are spoiling already :) So
no, nothing happened. 5 people want to develop the core relfs (any
other can just raise their hands) but I didn't ask anything to them,
since my work and my travels absorb me too much.

>        I develop a prototype as an example inside FUSE bindings. Actually, I
> head to translate a small part of FUSE into Common Lisp (it is
> modularized to simplify that exact task of translating/recombining the
> fuse_main) and find out just how dirty their symbol versioning trickery
> is... The project can be found at
> http://mtn-host.prjek.net/projects/cl-fuse/ , and the relevant
> "interface" part (stored queries, loaded on mount) can be browsed at
> http://mtn-host.prjek.net/viewmtn/cl-fuse/revision/browse/23483c4d94f7756d365626b247f82cdd588828e3/example-queries
>
>        I would be glad to hear comments about syntax, extension ideas etc.
>

I will look at it soon, as you know I am no lisp expert. However, can
you provide a personal judgment on your binding? How complete is it?
Did you test efficiency? Is it multi-threaded? Does it use multiple
cores? (the latter would be a killer feature if compared to ocaml).

>        Also, how Haskell-Rel-FS is going? What other ideas are there?
>

As I told you already that was only the idea of two developers, but in
the end it was decided that haskell even being multi-core was not
worth the effort.

>        Good bye, good luck.
> Michael Raskin

To you, but probably not really. Try to develop your idea, I will try
mine (one day, another day, we don't know). We will always be able to
exchange non-core code. And for now, if your filesystem works, I will
probably use it, so perhaps the next step would be to close this
project and follow you. For now it is better if we remain both  free
to experiment with our own ideas.

When you have a prototype alternative design, let me know on this
list, I will certainly be happy to take a look.

Vincenzo

[Relfs-devel] Post-OCaml development. CL-FUSE

[Michael R. <fb0...@ra...>]

		Hello, Vincenzo and hello, accidental reader.
	As of now, RelFS written in OCaml can be considered abandoned. We
decided to switch to some other design. So, what success do you have?

	I develop a prototype as an example inside FUSE bindings. Actually, I
head to translate a small part of FUSE into Common Lisp (it is
modularized to simplify that exact task of translating/recombining the
fuse_main) and find out just how dirty their symbol versioning trickery
is... The project can be found at
http://mtn-host.prjek.net/projects/cl-fuse/ , and the relevant
"interface" part (stored queries, loaded on mount) can be browsed at
http://mtn-host.prjek.net/viewmtn/cl-fuse/revision/browse/23483c4d94f7756d365626b247f82cdd588828e3/example-queries

	I would be glad to hear comments about syntax, extension ideas etc.

	Also, how Haskell-Rel-FS is going? What other ideas are there?

	Good bye, good luck.
Michael Raskin

Re: [Relfs-devel] CVS commit; and previous e-mail

[Vincenzo C. <ci...@di...>]

Michael Raskin ha scritto:
> 		Hello.
> 	Have you got my previous message, or was it filtered away? I just 
> wanted to commit a bunch of a bit tidied scripts, and some fixes to the 
> file system itself, but was unable to do it because of 'Insufficient 
> karma'.
> 	Please reply as you read it.. If I again get no reply I will probably 
> ask sourceforge support to add me to administrators of the project 
> because of impossibility to contact project administrator.
> 
> Good bye,
> 	Raskin
> 

You were not listed in cvs_acl, now you should be able to commit. When 
your changes are stable, can you please post an announcement on the 
mailing list with a summary of changes?

bye

Vincenzo

[Relfs-devel] CVS commit; and previous e-mail

[Michael R. <fb0...@ra...>]

		Hello.
	Have you got my previous message, or was it filtered away? I just 
wanted to commit a bunch of a bit tidied scripts, and some fixes to the 
file system itself, but was unable to do it because of 'Insufficient 
karma'.
	Please reply as you read it.. If I again get no reply I will probably 
ask sourceforge support to add me to administrators of the project 
because of impossibility to contact project administrator.

Good bye,
	Raskin

[Relfs-devel] Problems in e-mail address

[Vincenzo C. <ci...@di...>]

Hi all,

sending this e-mail also to some BCC

I just discovered that my sf.net e-mail address applejack at 
users.sourceforge.net was not being correctly forwarded, and mails to 
that address have been silently discarded for several months. So if you 
wrote to me privately and got no reply, please contact me again. My 
address seems to be working now, however the safest way to get me is to 
write to:

ciancia at di * unipi * it

(removing spaces and converting stars to dots)

sorry for that

Vincenzo

[Relfs-devel] (no subject)

[Michael R. <fb0...@ra...>]

I got no response for the previous copy of the letter, and in our times 
I can never be sure if a message got lost, so I resend it and also post.

---
	Hello.
I am now planning packaging RelFS for NixOS distribution. I noticed that
source tarball is still not there, and also I will probably add some 
scripts and will maybe do something for backing up. So I would like to 
have developer access to the project (some that is enough to add 
releases). I have registered as e62...@sf.... Please add me to the
RelFS project.

Thanks, goodbye
Michael Raskin

[Relfs-devel] (no subject)

[Michael R. <fb0...@ra...>]

Re: [Relfs-devel] RelFS usage.

[Michael R. <fb0...@ra...>]

Vincenzo Ciancia wrote:
>> After creating one more set of scripts for RelFS, I decided to post it
>> here
> 
> Ok I am almost back. Will be completely back after a couple of
> deadlines. You are welcome posting scripts, I will soon create an
> "utils" directory with shell scripts to do ordinary stuff, even though I
Good idea.
> think we should write some simple GUI, after stabilizing about the kind
> of common relfs usage.
Scripts are good because of being quick-and-not-too-dirty. I agree that
after deciding what we do need and what was a bad idea we can try to
write some usable GUI (to give people something to tease disappointed
former WinFS believers?).

>> , as it gives easy interface (too simplistic, but yet more than a
>> standard search in file managers would give) to create search directory,
>> where will be found all files which satisfy condition (I count symbolic
>> links as files).
> 
> I still haven't been able to study your scripts in detail, but I have
> some preliminary comments and many questions:
I expected this.

> 1. I don't like the "_create_" scripts that add things to a schema,
> would rather prefer to have a state in relfs where it scans for new
> addons, and when it finds them, it runs initialization code. This state
For this some negotiation is needed about plugin interface. With *create
scripts someone passing by (we should act as if there are some, and I
hope there are - I will be glad if some of them replies with ideas of
possible bleeding-edge user) can say why I did everything wrong without
any effort right now.

> should be entered at least on startup, or better when a certain
> directory containing plugins is changed. Your tags table can be at right
> considered a plugin for relfs, even though there is no indexing. This
> can be a good addition for a next snapshot of relfs.
Well, a good idea. My script show 2 things: how something like tags can
work, and how something can be easily added by user to RelFS - even
without OCaml knowledge.

> 2. Can you explain the schema of "tags"? Why are there (path,filename)
> pairs? Didn't the id suffice to find the file name? Why did you prefer
Well, I want to simplify possible searches in this database. I leave
using lookup on each occasion to my enemies.

> to introduce a "tag_value"? I always think of tags as boolean
> attributes, not quantities, even if the second idea is more general and
> can be useful to implement classification directories, it seems harder
I thought "What do I want?". I wanted to have some different
classifications all easily accessible. I want to automatically have list
of all programming languages I mentioned in tags. With special virtual
folder for each. I also want to have list by functionality program
provides. This way command-line completion works better... And I have to
choose two times - both times between similar notions in bearable
quantity (not between "OCaml" and "file system", but between "language"
and "purpose" and later between "OCaml" and "Shell").

> to use for navigation. In your case, you list all the values as
> subdirectories of a tag, aren't them tags in their own right then? In
They are, but they are grouped by category.

> fact a tag name already can contain slashes, so the two namespaces
Er.. I don't filter it, by I don't think it works.

> "tag/value" and "tag" already overlap, don't them? Finally, what's the
> meaning of tag_id? Could "id, tag" be used as a primary key for the
> table?
Well, it can. But this is polishing. I didn't want to restrict myself
before I complete anything. I didn't want to design well - I wanted to
test features.

> 3. What's the _uniquedata_ stuff for?
I understood that file cannot have 2 real sizes (for symbolic link, as I
store mainly symbolic links here - RelFS is good at categorization, but
right now I am just not ready to store all data on it - just like I do
not store /home on funionfs), and if I want to tag project tarballs that
bear my contributions also, this tag can be assigned only once. But it
can be reasonable to make 2 programming language tags - like when
Mozilla applications are written in C++ + JavaScript. So I made a table
as an alternative to tags when there is one main tag_value and rarely
ever second. It makes some search queries simpler and it allows to get a
quick summary of multiple files at once.

> 4. What's the symlinkize_dir script? Maybe we already talked about that
> in the past.
It is easy to work with symbolic links in RelFS (I have right to say so,
I guess). There are many technical problems with directories (I see some
in processing something like name/#select/name/#select path). So an easy
workaround is to make directory that you want to appear in search
technically symbolic link, and hide content somewhere near it.

> 5. How should relfs_search_text be used?
It is used in relfs_create_search only. It was used when I wanted to
debug the scripts. You can also just feed its output to SQL pipe to see
listing one time, without creating directories. I agree that it is
exposing implementation, but for proof of concept it is not fatal.

>> PS. On the site it is stated that I learned OCaml for this project. That
>> is not entirely true - I didn't learn it well, and I knew some basics
>> before. But I think that I more than doubled my skill in OCaml.
> 
> Oops, fixed :) Thank you for your help with the project, I will surely
Funny design solution for fix.

> add an "util" directory with your scripts. We should agree a schema for
> tags and the rest, and then also create some simple GUI to perform the
> same operations as the scripts, dunno if in ocaml+gtk or in python.
I agree with that. Maybe then it will be possible also to promote
project a bit, say by discussion of possible improvements (together with
finding volunteers) on LinuxQuestions.org or somewhere.

Re: [Relfs-devel] RelFS usage.

[Vincenzo C. <ci...@di...>]

> After creating one more set of scripts for RelFS, I decided to post it
> here

Ok I am almost back. Will be completely back after a couple of
deadlines. You are welcome posting scripts, I will soon create an
"utils" directory with shell scripts to do ordinary stuff, even though I
think we should write some simple GUI, after stabilizing about the kind
of common relfs usage.

> , as it gives easy interface (too simplistic, but yet more than a
> standard search in file managers would give) to create search directory,
> where will be found all files which satisfy condition (I count symbolic
> links as files).

I still haven't been able to study your scripts in detail, but I have
some preliminary comments and many questions:

1. I don't like the "_create_" scripts that add things to a schema,
would rather prefer to have a state in relfs where it scans for new
addons, and when it finds them, it runs initialization code. This state
should be entered at least on startup, or better when a certain
directory containing plugins is changed. Your tags table can be at right
considered a plugin for relfs, even though there is no indexing. This
can be a good addition for a next snapshot of relfs.

2. Can you explain the schema of "tags"? Why are there (path,filename)
pairs? Didn't the id suffice to find the file name? Why did you prefer
to introduce a "tag_value"? I always think of tags as boolean
attributes, not quantities, even if the second idea is more general and
can be useful to implement classification directories, it seems harder
to use for navigation. In your case, you list all the values as
subdirectories of a tag, aren't them tags in their own right then? In
fact a tag name already can contain slashes, so the two namespaces
"tag/value" and "tag" already overlap, don't them? Finally, what's the
meaning of tag_id? Could "id, tag" be used as a primary key for the
table?

3. What's the _uniquedata_ stuff for?

4. What's the symlinkize_dir script? Maybe we already talked about that
in the past.

5. How should relfs_search_text be used?

> PS. On the site it is stated that I learned OCaml for this project. That
> is not entirely true - I didn't learn it well, and I knew some basics
> before. But I think that I more than doubled my skill in OCaml.
> 

Oops, fixed :) Thank you for your help with the project, I will surely
add an "util" directory with your scripts. We should agree a schema for
tags and the rest, and then also create some simple GUI to perform the
same operations as the scripts, dunno if in ocaml+gtk or in python.

Vincenzo

[Relfs-devel] Addition to script set.

[Michael R. <fb0...@ra...>]

	Hello.
Today I have written three more scripts helping me to use RelFS. They
are listing tags I use though one is about filling them.

[Relfs-devel] RelFS usage.

[Michael R. <fb0...@ra...>]

Sorry, forgot to attach files first time.

--------------

	Hello.
After creating one more set of scripts for RelFS, I decided to post it
here, as it gives easy interface (too simplistic, but yet more than a
standard search in file managers would give) to create search directory,
where will be found all files which satisfy condition (I count symbolic
links as files).

I do not know if there will be any interest, and everything is in
obvious shell language, so I'd rather answer questions after they are
asked than before.

PS. On the site it is stated that I learned OCaml for this project. That
is not entirely true - I didn't learn it well, and I knew some basics
before. But I think that I more than doubled my skill in OCaml.

Good bye, good luck, happy New Year.
	Raskin Michael

[Relfs-devel] RelFS usage.

[Michael R. <fb0...@ra...>]

	Hello.
After creating one more set of scripts for RelFS, I decided to post it
here, as it gives easy interface (too simplistic, but yet more than a
standard search in file managers would give) to create search directory,
where will be found all files which satisfy condition (I count symbolic
links as files).

I do not know if there will be any interest, and everything is in
obvious shell language, so I'd rather answer questions after they are
asked than before.

PS. On the site it is stated that I learned OCaml for this project. That
is not entirely true - I didn't learn it well, and I knew some basics
before. But I think that I more than doubled my skill in OCaml.

Good bye, good luck, happy New Year.
	Raskin Michael

Re: [Relfs-devel] patch correction

[Vincenzo C. <ci...@di...>]

Michael's patch has been merged in CVS. I hope to be able to upload some 
binary release soon.

Vincenzo

[Relfs-devel] patch correction

[Raskin M. <fb0...@ra...>]

Hello. Testing showed that

+let absolutize_link path=
+        let s=(Unix.readlink path) in
+                if path.[0] = '/' then s
+                else let full_path=String.concat "/" ((Filename.dirname 
path)::s::[]) in
+                        if full_path.[0] = '/' then full_path
+                        else String.concat "/" ((Unix.getcwd ()) :: 
full_path :: [])


should be read as

+let absolutize_link path=
+        let s=(Unix.readlink path) in
+                if s.[0] = '/' then s
+                else let full_path=String.concat "/" ((Filename.dirname 
path)::s::[]) in
+                        if full_path.[0] = '/' then full_path
+                        else String.concat "/" ((Unix.getcwd ()) :: 
full_path :: [])


.
Sorry. I hope it works now.
Michael Raskin

Re: [Relfs-devel] Proposed patch: allow symlink selection.

[Vincenzo C. <ci...@di...>]

Alle 10:27, mercoled=C3=AC 12 luglio 2006, Raskin Michael ha scritto:

Nice job! You managed to understand relfs code without any previous=20
explanation, I wouldn't hope that much :) Thanks for your patch, just a=20
question:

> +let read_link path =3D
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0try Unix.readlink (lpath path) with
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Unix_error (_,_,=
_) =C2=A0-> match query path with

Why don't you match Unix_error(ENOENT,_,_)?=20

Apart from this, I would really like to have an additional field in query=20
directories for link contents, something like

"select '%%A' as name, '/A_DIR' as link_content"=20

which would return a directory containing a link named A and pointing=20
to "/A_DIR", however this and other similar things will need to be thought =
of=20
after many others. I must say that I didn't do many things for relfs recent=
ly=20
(except for the disambiguation scheme and the extended attributes stuff -=20
try "getfattr -d FILENAME" in relfs for example); I think that your patch=20
should motivate me to get back working on the project :)

Vincenzo

[Relfs-devel] Proposed patch: allow symlink selection.

[Raskin M. <fb0...@ra...>]

	Hello.

I send a patch for testing by other subscribers. It allows me to have 
not only regular files in query dirs, but also symlinks. Note that it, 
for example, allows you to have directories (but in indirect form) in 
query result, or even you can have a bunch of symlinks to devices 
residing out-of-the tree.

Michael Raskin

Re: [Relfs-devel] New RelFS prototype, with query ability - and binary release

[Jasper v. de G. <th....@hc...>]

Vincenzo Ciancia wrote:
> ...
> 
> Do you like this all or would you prefer another solution?

I think you summarized the discussion so far reasonably well.

Re: [Relfs-devel] New RelFS prototype, with query ability - and binary release

[Vincenzo C. <vin...@ya...>]

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