Re: SSD TBW

On 8/23/2026 12:01 AM, Old Macdonald wrote:
> On 8/22/26 20:57, Don Y wrote:
>> On 8/22/2026 8:51 PM, Rich wrote:
>>> In comp.misc Don Y <[email protected]> wrote:
>>>> Sadly, UNIX assumes file type is completely indicated by
>>>> a suffix on a filename -- said suffix being under the control
>>>> of the person who selected the filename.
>>>
>>> Nope.  You are mixing up ms windows (where the file extension is
>>> believed to always be right and descriptive of the contents) with Unix
>>> (which actually looks at the files contents and pays no attention to
>>> any part of the name).
>>
>> One configures applications (CVS in this case) to use the extension
>> of the file as an indication of how it should be treated.
>>
>> The contents still don't tell you what the file is or how it is intended
>> to be used.  Because no OS can infer the purpose of a "stream of bytes"
>> without having been previously informed of that.
>>
>> When a file (or, the metadata for the file) claims it is a
>> "FIGGLEBOB", then the OS can throw up its hands and claim
>> not to know how to handle it -- even if it looks like a shell
>> script, text file, TIFF, etc.  Because the explicit type declaration
>> has told it that it is none of those things, despite the resemblance.
>>
>> Is a .AI file a "text" file -- because the contents APPEAR to be
>> text -- even though they aren't really?  Is myprogram.q source
>> code in C, just because peeking inside LOOKS like that's the case?
> 
> 
> Search "magic numbers"
> 
> I looked at a few hits, this page is better than most, the first paragraph 
> should be enough.
> 
> <https://www.networkworld.com/article/931352/unix-under-the-spell-of-magic- 
> numbers.html>
Again, it only works if you tell the OS about your particular file type and
every other machine that will ever see files of that type.  That's what
Apple did, ages ago.

In UNIX, you only have the file name to rely on -- there is no other metadata
available to an application/system that wants to ascertain the nature
of the file/object that it is being asked to process.

In CVS, "wrappers" lets you associate "file types" with specific handling
options.  So, I can (effectively) say:

*	assume binary, as default
*.c	C sources
*.h	C headers
*.BMP	bitmaps
*.bz	BZIP archive
*.ppt	PowerPoint presentation
*.o	object, ELF
*.xwd	xwd(1) screen capture
etc.

Then, indicate how each "type" should be handled.  E.g., to check if a
"bitmap" coincides with another, do a binary comparison.  To show the
differences between them, create a two-valued map where one value
represents "agree" and another represents "differ".  For C sources,
create a context diff.  For powerpoint presentations...

If the creator of the files (e.g., a developer) is consistent in
his naming conventions, then creating such rules is (relatively) easy
and ensures the file isn't manglede by the VCS (e.g., replacing CRLFs
with LFs, keyword substitutions that weren't intended, etc.)

You can *manually* tag individual files -- but, then you may be faced
with thousands of such tagging operations (especially when importing
someone else's sources)

For example, I have bitmap called M.A.C.C. -- how should it be treated?

And, "ReadMe" matches the "default" wildcard so should I treat its
contents as "binary"?  Or, add rules:

ReadMe	special notes
Makefile make(1) rules
makefile make(1) rules

This mess because UNIX doesn't let an application (that created a
particular file!) *tag* that file with a specific "type".