-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
[email protected] wrote:
> On Sun, 26 Jun 2005 14:58:07 CDT, David Masover said:
>
>
>>"Plugins" is a bad word. This user's combination of plugins is most
>>likely identical to other users', it's just which ones are enabled, and
>>which aren't? If they are all included, I assume they play nice.
>
>
> Which ones are enabled. Exactly.
I doubt there will be duplicate plugins, once things settle down. So
you just have the program demand certain ones to be enabled.
>>And just because they are called "plugins" doesn't mean the EA looks
>>different every week.
>
>
> They do if the one enabled this week is "make EAs look like symlinks", and
> last week's was "make EAs look like folders".
We could just as easily do that with other extended attributes. Sure,
the details would be different -- maybe we just randomly add a XA onto
the beginning of every string.
> (Don't blame me, *you're* the one that said "EAs can look like any other object"..)
Doesn't mean we can't guarentee a certain kind in a certain
configuration will always be available for a certain plugin, once it's
been accepted.
>
>
>
>>>And 'cat crypto/raw/foo' or 'crypto/inflated/foo.gz' gets you what, exactly
>
> ?
>
>>>Now throw some .bz2 and .zip files into the mix... ;)
>>
>>Interface is the same. Only, zip files aren't just compression, so
>>maybe the interface changes a little there.
>
>
> Right. So please explain what crypto/raw/foo and crypto/inflated/foo.gz give you.
In that example (shouldn't have used the name "crypto", but oh well), it
should be crypto/raw/foo.gz and crypto/inflated/foo -- where foo.gz is
the gzip'ed file and foo is the transparently compressed/decompressed
file. Basically, these are equivalent:
$ zcat crypto/raw/foo.gz
$ cat crypto/inflated/foo
>>Point is, now you have a standard interface for any program to access
>>any simple lossless compression, transparently.
>>
>>
>>>>Another possibility, if you like file-as-a-directory:
>>>>
>>>>cat foo.gz # raw
>>>>cat foo.gz/inflated # decompressed
>>>>
>>>>One could easily imagine things like these two potentially equivalent
>>>>commands:
>>>>
>>>>cp foo bar.zip/
>>>>zip bar foo
>
>
>>>Unless of course the user had done 'mkdir sorted.by.city.zip' to make
>>>a directory of files containing data sorted by USPS Zip code.
>>
>>What's this got to do with anything?
>
>
> It's got a *LOT* to do with it if I created a *DIRECTORY*, to use *AS A DIRECTORY*,
> the way Unix-style systems have done for 3 decades, and suddenly my system is
> running like a pig because the kernel decided that it's a .zip file.
The kernel does not decide that. You do. And it doesn't automatically
decide that every time you create a file. You have to use some
interface to trigger the plugins.
Originally, this was file-as-a-directory. Now? I'm not sure, I guess
we could use a separate delimiter. Something like:
foo # file
...foo # directory containing xattrs of file, list of plugins used.
foo/ # directory
foo/... # directory containing xattrs of file, list of plugins used.
I guess I need a new name for this approach. That's three possible ways
of doing this?
>>>And what happens if the user has a file 'bar' that's not a ZIP file,
>>>and a directory 'bar.zip' isn't a view into 'bar'?
>>
>>In file-as-a-directory (which is probably NOT happening soon), bar.zip
>>is both the actual zipfile and the view inside, depending on whether you
>>try to open() it directly or peek inside it as a directory.
>
>
> Ahem. "bar.zip' is a *DIRECTORY*. I said 'mkdir bar.zip' - why is it not
> acting like a directory?
If you said "mkdir", it would act like a directory.
More likely than foo.zip/bar would be foo.zip/.../contents/bar. Which
would also work for tarballs. But would not automatically compress
anything you didn't want it to.
>>However, let's not discuss this now. I do NOT want to start another
>>"silent semantic changes with reiser4" thread. File-as-directory is not
>>happening this time, so don't worry about it -- this time.
>
>
> Fish or cut bait. You are the one who started handwaving the 'file-as-directory'.
> If you don't want it discussed, don't mention it.
I do want it discussed. I'm not sure it's a good idea now. But looks
like you got me...
>>>Most of the time, if I have a file 'linux-2.6.12.tar.bz2' and a
>>>directory 'linux-2.6.12', what is under the directory is *NOT* the same
>>>data as what's in the .bz2 - I've done 'make oldconfig' and a few builds
>>>and some variable amount of patching, usually with rejects, and I *don't*
>>>want that .bz2 being updated during all this (hint - what's my next command
>>>after 'rm -rf linux-2.6.12' likely to be, and why, and what expectations
>>>do I have when I do it?)
>>
>>You're misunderstanding. man zip.
>>$ zip bar foo
>>creates/modifies a file named "bar.zip", not "bar", which contains the
>>file "foo".
>
>
> No. *YOU* are misunderstanding. I have a directory 'linux-2.6.12', and
> I have a file 'linux-2.6.12.tar.bz2', and I do *NOT* want directory operations
> to be silently converted into "let's scribble into the middle of this tar file
> and then compress it". (Hint - work out how long a kernel 'make' would take
> if you were doing it inside a .tar.bz2).
I remember discussing that, actually. It wouldn't automatically do this
if you didn't want it to, but it would be nice if, say, it was something
truly seekable like linux-2.6.12.zip, and linux-2.6.12 was a
user-created symlink to linux-2.6.12.zip/.../contents, and we had a nice
caching system...
This is nice because then you get exactly the same performance during
"make" as you would with "unzip && make", only better, because files you
don't ever use (lots of arch, for instance) are not unpacked.
This is all something that's been discussed before. I think the
consensus was that it sounded cool, but not useful enough by itself to
justify file-as-a-directory.
You can always go re-read "Silent Semantic Changes..."
>>>You want to think this sort of thing through *really* thoroughly, because
>>>there's a *lot* of things, both users and programs, that have expectations
>>>about The Way Things Work.
>>
>>Or, I can avoid those issues altogether, and simply delegate this kind
>>of stuff to user-created-but-magic directories. For instance, I could
>>have a directory called "/foo" which contains encrypted files, and
>>"/foo/decrypted" which has transparently decrypted representations of them.
>
>
> So rather than everything working in a funky manner, a program gets to guess
> how funky, and in what direction, a given magical directory is....
It doesn't have to guess, it can know if it needs to. Although this
probably wreaks havok on traditional backup systems. You'd have to
implement a somewhat new backup system, but it's not impossible, and
certainly doesn't require that your new backup system know about every
plugin -- just make sure plugins know about backup.
Of course, file-as-directory avoids all that -- you just have to patch
programs to know that if foo/ exists or foo responds to opendir, foo is
not necessarily a directory. You probably just drop the trailing / and
use stat().
Both (all three?) appraches have cans-of-worms and workarounds. But I
think both (all three?) are doable. I know user-created-but-magic is
doable.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iQIVAwUBQr8txHgHNmZLgCUhAQKOxA/+KP1lmUgmrbEH+kPKriSFF3qFfFBgbeJh
iebHVaOY4AMa99a3yHy8iA5ZyE5N2b3CEueoq44ygYs5gqeft1IF14SJweNk/6or
IgGt+OsAkqDMdbbpKZdDGo8lZK0bJq/Ni+PMzx44sMGg4vWIHGAQfDGZ9FYRmrRT
fLNprUrkUsIzVEDHcuYjrZfPHvqr4HK8KXa5IJIKj6WkCYj5gxkQlH3g9zEaWXlN
Mfsqr6uioK34vKEgQw9HvpDpMZaB5NpZ7RWr5vEP3G3AV120VNKIEqU09Pex/IJD
oiOaroR7y1OZUaLuTSyut+4MGjHJ7k6TNr8H/CFdRfpLs7mP5tsJG42rzAhqTdyP
2D2m7sgpEN8ALkGd+IU3ihLOVQCrSq2T0jpr6tFhDe5uTenP3fXBeGgu8ynRzPFD
kkpyZhT094UWKoq8n+IcHQrIcba4j6X/jDJt7SDx8IwfZaPoMpcBGQH1//Q+lTuC
q5qM7olI5OzcSr4AhDld7OOjqO0pLXRfH5y8hy8mgWEiGgomK+N5OFTqXrQsuB/g
BopfBpqHRRYVpI1VkAutmTpyNjm3dQjrHmRWXX2sFe9lxExpWo9VX4By9ytv9EXQ
UFfSBF9TVe+EkZ4XxO+JMCcahNUsBh45rRXY3wVpH1qPwsOVp8FxYcOmuzQSTha9
mgOxWbRfqkQ=
=jrll
-----END PGP SIGNATURE-----
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
