file attributes

[Erik M. van der Poel]

Martin C. Atkins writes:
> erik at srava.sra.co.jp (Erik M. van der Poel) responds to my message:
> > It does not take up very many resources to map registered names to
> > system-specific values. E.g. "FrameMaker" -> "/usr/bin/fm" (or
> > whatever).
> 
> This is *not* what I meant! I meant good old-fasioned *human*
> administration!

Oh, OK, I see your point. Yes, we will need human resources.


> Otherwise we would end up with attributes such as
> `EXXy55' meaning ``secondary application to invoke when double clicked
> while meta shift left elbow is valid...''

This is *not* the sort of attribute to attach to a file. This is
something to attach to a user. You might attach the attribute "text"
to a text file, but not "vi".


> This would mean
> that many (well meaning) developers would simply allocate their own
> attributes, for development and testing, while the bureaucracy gets done.

I agree. We will need a flexible system for temporary local allocation
of names.


> Yes, and many well-intentioned organizations have been producing
> PERFECTLY DREADFUL standards for years! Such standards deserve
> to be ignored.

Some standards deserve to be ignored. The standards process itself
should not be ignored (in my view). More people should take part.


> Please show me how to change one of the header lines to a value longer
> than the current value (or insert a new header line), WITHOUT having to
> copy the rest of the file

You just read the metadata into a buffer, editing the line you want to
change as you do so, then write the buffer out to the file's metadata. 
If the system implementation keeps the metadata and data separate, no
copying of huge sound files is necessary.
-
-- 
EvdP