> You are doing a syntax assumption, and seem to be only discussing
> syntax. I'm talking about a set of semantics - in this case the
> fact that (a) opening the file will give the normal data fork, and
> (b) you can't just rename something out of a fork, and (c) you get
> a clear distinction from user-created directories.
OK - I take the point here. Using forks for metadata or resources
means that the main fork is still accessible by ignorant programs.
Even so - because ignorant code needs to, or will be looking at the
main fork, and not auxiliary forks, it tends to depreciate the value
of those additional forks (because things like cp and tar won't copy
the other forks, you need to do extra work in some situations like
backups anyhow).
And - if applications need to be written to be fork aware, we might
as we write them to use abstracted directories or something.
So, yes, I admit, that one nice feature of forks is that existing
applications can still interact with the data in part (the default
fork), but to get full benefit from forks, applications may need to
be re-written in which case we don't necessarily have to use a
kernel/file-system implementation for forks - we can fake it in a
library.
-cw
-
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.altern.org/andrebalsa/doc/lkml-faq.html