On Sat, 12 Aug 2000, Pavel Machek wrote:
> >
> > and then access the "Icon" resource in it by just doing
> >
> > xv ~/myfile/Icon
>
> Sorry, this is not going to work. I played with this with podfuk, and
> xv will probably stat myfile (just for fun), notice it is regular
> file, and refuse to try to open myfile/Icon.
>
> What you however can do is xv ~/myfile#utar/Icon. This actually works
> for me.
I don't think this is a strong argument. Any program that "knows" that it
is handling a POSIX filesystem and simply does part of the work itself is
always going to break on extensions. That's just unavoidable. Adding the
magic string at the end makes "xv" happy, but might easily make something
else that assumes POSIX behaviour unhappy instead (ie somebody else does
'stat("myfile#utar")' and is unhappy because it doesn't exist).
Tough. Whatever we do, complex files are going to act differently from
regular files. Even a HFS approach that looks _exactly_ like a UNIX
filesystem will confuse programs that get unhappy when the resource files
magically disappear when the non-resource file is deleted.
Also, note that we can always break things up: even in the presense of
programs that _require_ POSIX behaviour because they think they know
better than the OS (silly thing to do) you can always just do
cp ~/myfile/Icon Icon.bpm
xv Icon.bpm
cp Icon.bpm ~/myfile/Icon
instead. I'm personally worried not about individual programs not being
able to take advantage of the resources, but about Linux fundamentally not
_supporting_ the notion of resources at all.
So what I want to make sure is that Linux supports the infrastructure for
people to take advantage of resource forks. The fact that not everybody is
going to be able to do so automatically is not my problem.
[ Put another way: I suspect that we won't support resource forks natively
for another few years, and HFS etc will have their own specialized
stuff. I don't care all that much. But at the same time I do believe
that eventually we'll probably have to handle it. And at _that_ point I
care about the fact that our internal design has to be robust. It
doesn't have to make everybody happy, but it has to be clean both
conceptually and from a pure implementation standpoint. I don't want a
"hack that works". ]
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Aug 15 2000 - 21:00:30 EST