Messages in this thread | | | From | (Linus Torvalds) | Subject | Re: NTFS-like streams? | Date | 12 Aug 2000 13:35:41 -0700 |
| |
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/
| |