> With all this arguing about resource-fork implementations, I felt
> an outside perspective might be valuable. Maybe not, but here it
> is anyways. :) I am not participating in any projects (meaning I
> am unbiased)
Sure, "unbiased" all right...
> First I ask, what is the point? I can see two potential applications:
>
> 1) You can use regular file tools to manipulate directories. Is this really
> important, or just a parlor trick to amuse one's friends? What is so
> evil (or hard) about:
>
> (cd /srcdir && tar cplf - .) | (cd /destdir && tar xpvf -)
>
> or cp -a (for linux) or cp -Rf (for all other *nixs)
Do that on NFS over a shared Ethernet and have people hate you.
The SMB filesystem (not our implementation) can support that operation
on the server, saving network bandwidth and preserving security data.
The above has little to do with multi-forked files though. One may
use directory-like structure as the internal representation of a
multi-forked file, but multi-forked files are still seen as files.
> 2) You can use it to break down complex files into a series of less complex,
> but related files, for applications such as word processors, desktops,
> spreadsheets, bla bla bla. This would be for the purposes of:
You don't break files down into files. You break files down into
subfile components that share file attributes. This is like threads.
(note that Linux threads are not POSIX because they are too process-like)
> 1) As had been stated by several people before, anything that comes out of
> this in the form of a linux-specific kernel change will go the way of the
> dinosaur for the following reasons:
>
> - Many won't consider adopting it due to the non-portability
> - and if it goes into Linux, other vendors won't likely
> implement it for their OS due to the inevitable GPL nature
> of the code. (Remember, not everyone has warmed up to open
> source, and of those that have, many are still hostile to
> GPL.)
FreeBSD people maintain Linux emulation code. As soon as they copy us,
every commercial vendor will be able to add support. The existance of
two implementations would be good.
> - Users will reject it, as it will break their existing programs.
> - I don't think examples are needed here. They are self
> evident. But I shall provide one. I actually rely
> on 'mv * /newdir' NOT moving directories.
According to Unix98, you may not rely on that. If /newdir is on the
same filesystem, the OS _must_ move directories. If the OS supports
cross-filesystem hard links, the OS _must_ move directories. Your
command can only fail when it crosses a mount point on an OS that
does not support cross-filesystem hard links.
> The 'cat' vs.
> 'cp' issue raised by cbbrowne@godel.brownes.org is also
> shows such things to be unworkable.
Nope. You can 'cat' and 'cp' all you want. The worst that can happen
is that you end up with a less-efficient non-forked representation of
the file.
> 2) This can all be done in user space (save the using cp to copy a directory
> parlor trick). Theodore Y. Tso's document re: this shows this to be
> entirely true. The difference is I don't even think a libc hack is
> appropriate (save the case of the POSIX people creating some kind of
> resource fork standard)
For perhaps the first time, I agree with Ulrich Drepper. The LD_PRELOAD
hack is simply unacceptable for normal use. Don't touch libc.
> Why should the kernel and/or libc be responsible for being able to
> deconstruct a file into it's base components? That's what an
> application-level API is for!
Performance is a good reason. Would you mind if Linux was losing office
suite benchmarks by a factor of 1000 or more?
> I don't really care that I won't be able to
> use 'xv' to view the images in my word-processing files. If I want to
> look at them, I'll fire up the word processor.
>
> Should I actually have a need to extract said files, then (assuming all
> open source software is involved) I have the APIs for the word-processor
> file format, and I can use that to preform this (you have to admit)
> special-purpose task.
Well, we agree on something.
> Another thing that might be worth looking at (I've not seen any dicussion
> WRT this yet) is how existing resource forked filesystems work under Linux.
> I've just looked at the documentation for HFS (Apple) for the Linux kernel.
>
> My first impression. It's ugly. All kinds of dot files for this, that, and
> the other thing. I know I don't want my Linux to work that way. And I know
Do you realize why HFS support is ugly? We don't support forked files!
HFS is not at all ugly on an OS with proper support, such as MacOS.
> could take care of launchers, etc, and something like an icon could be
> stored in a dot file of some sort.
Icon data belongs in the executable. Executables could be normal ELF
binaries or multi-forked files -- it does not matter. If a user doesn't
like the icon... well, we don't let users change the code either.
Users that override the code must change $PATH, and users that override
the icon can do the same sort of thing. No problem.
> ps: regarding the semantics of filesystems needing innovation, there's an
> old saying that goes 'If it ain't broke, don't fix it.'
You have a 1.5 GB compound document.
It contains 3 evenly sized parts.
You want to extend the middle part by one byte.
ps: let's just wait until we know exactly what Samba and Wine need
-
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/