• Just a comment

    From philo@21:1/5 to All on Mon Nov 1 18:32:03 2021
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Aragorn@21:1/5 to All on Tue Nov 2 01:37:27 2021
    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 =

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Paul@21:1/5 to philo on Mon Nov 1 22:13:02 2021
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From philo@21:1/5 to All on Tue Nov 2 05:58:50 2021
    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 .

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From philo@21:1/5 to All on Tue Nov 2 05:56:12 2021
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)