*cough* *choke* *gasp* Andrew cluster *splutter*
I suspect Ted could make a similar remark with respect to MIT... then again,
probably not. (HESIOD?) (I've yet to figure out why CMU thinks that local
password files are a good thing....)
| One could also envision the file itself being associated with database
| entries. In this context the copying of the file will copy the entries
| as well. If one would attempt to copy the file outside of ext2 that should
| produce those ".fork" database files.
+--->8
One thought I had was that read() on a file with metadata returns a
structured file containing all the data and metadata *unless* the program
issues an fcntl() to switch to metadata mode. (Note that metadata/"forks"
and databases are not disjoint --- Mac System 6 and later, IIRC, use a btree
for the resource fork.) Having done that, read() returns only normal data
and other fcntl() operations are used to access metadata.
If you hide the fcntl()s and metadata-aware read() inside other functions,
you also get an API which could be implemented as a library on systems
lacking metadata (the physical disk file actually is the above structured
file) --- and to provide cross-platform metadata routines for Mac, NTFS,
OS/2, etc. Of course, at this point the claim could be made that one
doesn't need the fcntl() stuff, just the library (but! it will perform
horribly unless the "structured file" is really a file and a backing (e.g.)
reiserfs directory --- in which case you can lose by not realing that you
need to copy the directory as well as the file.
-- brandon s. allbery [os/2][linux][solaris][japh] allbery@kf8nh.apk.net system administrator [WAY too many hats] allbery@ece.cmu.edu electrical and computer engineering KF8NH carnegie mellon university
- 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