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

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

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.