Re: File types [was: Re: wide characters and i18n]

[markucz%gmail.com@localhost]

> I still do OS upgrades via "Backup, check the backup, clean
> install, reinstall applications" process. :-) :-(
Good and tried method, regularly used here too.

>> Having used MacOS only occasionally, I remain blissfully
>> ignorant about its quirks and resource forks are still a
>> mystery to me. 
> They're "alternate" data streams. Originally for program icons
> and such I believe.  Officially they're deprecated.
> Unofficially OS X applications and programmers can't quite
> give them up, seemingly.
> 
> Windows (starting with NT?) has something similar, but that
> I'm not familiar with.
I don't understand what "alternate" means in this case. Is this "data stream"
kept in the executable itself (that's what Windows does with icons, IMO since
3.x) or in a separate file but still being treated as a part of the
executable (like DOS overlay files)?

> ACLs (IMHO -- this whole post is IMHO :-) should not be
> an add-on to traditional Unix groups: pick one or the
> other, and stick to it.
IMO you're right :-) but some people want to have ACLs, MAC and whatever else
it takes to become B1 compliant "Trusted $OS" and hopefully make big buck$.

> In practice I have never had a situation where Unix group
> membership (if necessary, with a setgid and/or setuid
> accessor program) did not suffice.
I don't particularly like set[ug]id wrappers and creating new groups every so
often for usually trivial/mundane tasks. Still, Unix groups are easier to
manage.

> A magic number in a binary file is different: only programs
> already familiar with the file format care about the magic
> number, and so can be taught to check for it at the same time
> as they're taught the entire file format.
This again brings up the question if files are just bags of bytes or not. I'd
say text files are just another file format. There're just too many programs
which deal with it. Here Plan 9 got it right - assume all text is UTF-8 (I
leave aside considerations about file size or bandwidth wasted) and add some
functions to libc if needed. "Assume all text is ASCII" is just as valid
though.

> But it's close to all or nothing: open(), read(), write(),
> close() isn't enough to replicate the file anymore.  (I
> suppose, to be fair, it isn't on Unix either: you need stat(),
> chown(), chmod(), etc ... but still, _every_ application that
> copies files has to know about any new functionality.)
I believe XFS has xattrs by design so I wonder if all Irix programs were
written to be xattr-aware or if it was pushed down to the filesystem level.
Maybe that's the right approach?

Best regards