I often retrieve data from old computers and a while back a friend gave
me the HD from his old Mac.

It had documents created in WordPerfect 3.0 and they had no suffixes.

Though on Windows, I can specify that Libre Office open the file, when I
looked at properties, it did not identify it. On Linux, it opened with
Libre Office of course but under properties it was also able to identify
it as a Word Perfect document.

Nice

On 01.11.2021 at 18:32, philo scribbled:

> I often retrieve data from old computers and a while back a friend
> gave me the HD from his old Mac.
>
> It had documents created in WordPerfect 3.0 and they had no suffixes.
>
> Though on Windows, I can specify that Libre Office open the file,
> when I looked at properties, it did not identify it. On Linux, it
> opened with Libre Office of course but under properties it was also
> able to identify it as a Word Perfect document.

That's because Windows identifies file types by way of the filename
suffix, whereas UNIX identifies files by looking at the magic bytes in
their header and comparing those to /usr/share/file/misc/magic.mgc,
which is itself a binary file containing a list of known file type
signatures.

The command "file" works the same way, and is often executed in the
background by the GUI application trying to identify a specific file.

$ man file

More information at...

https://en.wikipedia.org/wiki/List_of_file_signatures

--
With respect,
= Aragorn =

On 11/1/2021 7:32 PM, philo wrote:
> I often retrieve data from old computers and a while back a friend gave me the HD from his old Mac.
>
> It had documents created in WordPerfect 3.0 and they had no suffixes.
>
> Though on Windows, I can specify that Libre Office open the file, when I looked at properties, it did not identify it. On Linux, it opened with Libre Office of course but under properties it was also able to identify it as a Word Perfect document.
>
>
> Nice

The old MacOS used a "signature", to record
similar information to a file extension. Rather
than place .txt on a file, you can stamp it
TEXTttxt with FileTyper third-party software.

https://www.macdisk.com/macsigen.php

TEXTttxt would be a Text file created by TeachText (ttxt).

Using an application like "Filetyper", you could drop a data
icon onto the Filetyper executable, and edit the "TEXTttxt" thing.

When things other than TeachText see the TEXT???? part, say
BBEdit Lite, it can still open the text file. So in a sense,
the "type" field of the signature works the same as putting
..txt on the end of the filename.

But if I wanted to double click my data file, and I expected
BBEdit Lite to open the file, then the ttxt portion of the
signature would need to be changed to the value for BBEdit.
Using FileTyper on the BBEdit Lite executable, would likely
give you the required four character field for modifying
a text file.

And it is also still OK, for a file to have its own "magic bytes"
in the data fork of the file. That means, when a cross platform ready
file is moved to another platform, the /etc/magic method can be
used to control what application tries to open it.

Files on the Mac in 9.1, would consist of a resource fork and a
data fork. The data fork is the equivalent to the main file portion
on other OS setups. Thus, a TEXT file, could have a 10KB data fork
(containing the same .txt type content that other platforms
could eat without much of a fuss). The Resource fork in such a
case, could have a size of zero.

If the file is handled by the AppleDouble application, the resource
and data forks are combined into a single file. This allows sending
a Macintosh file across the Internet, without the wheels falling off.
When the file arrives at its destination, the recipient would use
the AppleDouble thing to put the file back on the Macintosh disk drive
with a 10KB data fork, and a 0 byte resource fork.

Executable files, those can have significant-sized resource forks.
Losing the resource fork via careless cross-platform handling
would destroy the portable executable.

Thus, a Macintosh user is "more aware" of their surroundings
than Linux or Windows users. As they have "more to lose" :-)

Windows has alternate streams on NTFS, but there isn't a fuss about
preserving the Zone.Identifier stream. if that is lost, nothing of
value is lost. Microsoft has so far, placed only "the bath water"
in Alternate Streams, and if such forks are lost in transmission
across the Internet, nobody really notices or cares. At one time,
Kaspersky was marking files it had scanned, with an alternate
stream similar to the Zone.Identifier. And again, careless handling
of the file during transport, only the "proof of scanning" would be
lost, which is also a "who cares" condition.

The old MacOS 9.1 was full of fun. You kept your FileTyper handy, for
"stamping" files so that your favorite application would open them.
I think I was re-stamping PDF files so Acrobat Reader would open
them by default, on subsequent attempts.

The signature is not stored in the file, but is store elsewhere on
the disk, as the above URL explains. That means the TYPE:CREATOR
field isn't competing with the /etc/magic bytes. If a file is transported
to a Unix or Linux box, the TYPE:CREATOR are lost, and the Unix or
Linux box rely on /etc/magic to use LibreOffice on your file. And
that works, as long as the softies who made the software that
made the file, included magic-like bytes at the start of the
file, suited to the job. The first eight bytes of a number of
MSFT files, helped identify what they were while on the foreign platforms.

I would say "Nice" but "Danger Will Robinson, Danger". Take extra special
care of those user files, or you could "lose half of them". The Resource
fork half.

Paul

Thanks Paul.
As I so often find out, I learn a lot from seeing how things work by examining the roots.

In a way, I think examining a 25 year old operating system is very much like archeology .

Thank you.
As always , one more world is opening up for me.

Btw: I was just given quite a few old Macs and had enough parts to get two working.

I loaded the Power Mac with OS9 and put the text files on it and was able to print them out on my networked printer using the generic Postscript driver.

Not only did it print out the text, it also printed out the internal identifier which specified WP 3.0