[Samba] big file server

[Dragan Krnic]

>> reiserfs complies fully with APIs for ACLs
>> and EAs. Unfortunately, samba team would rather
>> start writing non-POSIX samba from scratch than
>> use the elegant transparency of reiserfs's streams.
.............................
>
>Errr. What brought this on ? What gave you the idea
>that we're (a) writing a non-POSIX Samba or (b) 
>rewriting Samba from scratch ?

Duuuh, you must have had to go to the bathroom just as
Tridge was passionately pitching his "Beyond POSIX"
plea for Samba 4.0 :-)

But seriously, Jeremy, if you read my quote again,
you should note that it neither says nor purports
to say that you are either (a) writing a non-POSIX 
Samba, or (b) rewriting Samba from scratch.

It is a not so uncommon figure of speech where the
absurdity of one sentence enhances the sillines of
the other - I forgot the Greek word for it.

To put it in Usian, my letter says that the so-
called "multi-dimensional" files, as Tridge put it,
or simply multiple file streams, should be within
reach of Samba, if Samba wizzards cared and/or had 
enough manmonths to pull 'em out of their white hats.

Correct me if I'm wrong, but aren't streams merely
files in ars (as in ar(1)) with fancy marketing
name? If it sells WinDoze, it can't hurt Samba.

>The problem is there is no POSIX API for streams. I'm
>willing to abstract any reasonable API so we can have
>streams on systems that support them. We will probably
>add extended attributes now Linux supports them.

Sure, there is no POSIX API for ACLs and EAs either,
that couple of proposals will forever be discussed by 
the hair splicers on the 1003.1e. That doesn't mean 
we'll wait until they have decided. The ACLs and EAs 
from bestbits.at is de facto standard because it's 
there and people can use them. Not quite as extensive 
as M$ ACLs, but quite a workable start in right
direction - the only limit is our imagination.

I guess it's only the lack of said imagination that 
prevents us from using them 1:1 against SMB. Say,
for example, why don't we put the system, archive, 
hidden and read-only bits in EAs and sweep a lot of 
ambuguity out of Samba source? Who cares if those
bits mean nothing to Posix-compliant apps if they're
as well as exclusively used in samba shares and Samba
is aware of them? Those utilities that need to be 
aware of them will grow to accept them after the fact. 
It's the chicken and egg dilemma all over again. If 
Posix stands in the way, by all means we should make 
it better, even if we have to consciously ignore it 
until it catches up. Precisely this kind of rebellious
civil disobedience brought us the possibility to 
approximate winfs's state of mind with those seemingly
superfluos bits. Now it's time to move on and use 
what's as good as approved POSIX.

Few of the things that M$ does are POSIX compliant.
That doesn't keep Gates from coralling almost all
the sheep in his backyard, to say nothing about the
greenbacks. But by doing so, M$ established a number 
of de-facto standards with more normative power than 
the Posix cabal. Witness Samba.

I'm not an expert on reiserfs, only an extremely
satisfed user, but from what little I've read about 
the concept behind that endevour, you should be able 
to just put another slash behind a "unidimensional" 
file name and access whatever you fancy, call it 
extended attributes, streams or whatever. Why is it
not used in Samba?

Cheers
Dragan



____________________________________________________________
Get advanced SPAM filtering on Webmail or POP Mail ... Get Lycos Mail!
http://login.mail.lycos.com/r/referral?aid=27005