In article <399555EB.F29C5937@flyingbuttmonkeys.com>,
Michael Rothwell <rothwell@flyingbuttmonkeys.com> wrote:
>Rik van Riel wrote:
>
>> When you _do_ want to have these things transferred, you can
>> use a modified tar (or cpio or pax) archive format. Just like
>> the "standard tar" stores the normal unix attributes, it should
>> store the extended attributes.
>
>Yes.
Note that this is something that the Mac community (and others) have
handled for a long time.
The same way unix users use "tar.gz" files, mac users use their own
zipped files ("binhex" etc). It's not all that different, in the end.
Doing this kind of support properly in Linux would probably imply that
we should add another bit to the "mode" flags to indicate "complex
file", so that programs could test this properly without having to try
to do a readdir on every single regular file. The current "stat64"
interface does have 32 bits for this, of which we actuall yonly use 16
for the historical unix st_stat.
Note that the alternative (that I think AUX used for doing the Mac
filesystem: it was obviously quite important to them) is to really show
resource forks as directories all the time and not even have the notion
of a "complex file" at all. The difference from a VFS perspective in
Linux is pretty much negligible: whether you open
~/my-complex-file/default
or whether you can open the complex file directly (ie an "implied"
default fork by just opening ~/my-complex-file directly) is not
something the VFS interface should really care about. However, I don't
think it's a very nice user-interface to force the "files with resource
forks are always seen as directories" notion upon users. It defeats the
_nice_ properties of resource forks (ie not forcing people to be aware
of the secondary data).
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:28 EST