Old files are now Unix Executable

Files from OS 9 and earlier (in particular) were tracked by the Type and Creator codes in their resource fork data so the OS would know, more than anything else, what app it belonged to.

These were deprecated all the way back in Snow Leopard. macOS stopped paying attention to them entirely starting a few versions back and now uses a combination of file extensions and Uniform Type Identifiers. What you're looking at is the OS' way of saying, "I have no idea what this is."

If you know what app they're from, you can add the appropriate file extension. For Microsoft Word, it would be .doc .

The real problem is finding any app that will show you those codes. File Buddy is one, but I'm not sure if it has a demo mode. If you can use it (at least for a few days), this is what you want to find out. In this example, I did a Get Info on an old PDF file.

Type and Creator codes always have four characters each. CARO indicates Adobe Acrobat created the file. Type is PDF(space).

This is what you want to know on all of these old files in order to help figure out what they are. Such as, any file with a creator of 8*** is Photoshop. ART5 is Illustrator.

Oh, man! That's useless. Just had a chance to test it today and MuchoFileInfo is strictly an OS 9 Classic app.

So, here's one that's free and works in Mojave or earlier.

https://www.everydaysoftware.net/quickchange/

It's an unsigned app, so you need to right click on it and choose Open to get it to launch. After that, just drag and drop your Exec files on it to see if they have Type and Creator codes. Here's the result of me dropping an ancient Photoshop TIFF on it:

Kurt,

Would you try this on that old Photoshop TIFF file? It will prompt you for the image, and display creator and type codes if it can plumb them from the file. Copy/paste into Script Editor, and click the document icon in the Script Editor bottom margin so you can see the document attributes in the bottom panel.

use framework "Foundation"
use AppleScript version "2.4"
use scripting additions

property NSFileManager : a reference to current application's NSFileManager
property NSString : a reference to current application's NSString

set infile to POSIX path of (choose file default location (path to desktop))

set fm to NSFileManager's defaultManager()
set arec to fm's attributesOfItemAtPath:infile |error|:0
log (arec) as record

set fname_ext to (NSString's stringWithString:infile)'s lastPathComponent()

set creator_code to arec's valueForKey:"NSFileHFSCreatorCode"
set type_code to arec's valueForKey:"NSFileHFSTypeCode"

if not class of creator_code is "text" then set creator_code to "n/a"
if not class of type_code is "text" then set type_code to "n/a"

display dialog "Creator: " & creator_code & return & "Type:      " & type_code with title "File: " & fname_ext
return


Yeah, I wasn't sure if you could use that. I've had a registered version for a long time and couldn't remember if it had a demo period.

You used to be able to find Type/Creator viewers and editors rather easily, but most of them only worked in OS 9 and earlier. The only one I have that would work in El Capitan is the free Mucho File Info. But I can't find that one anywhere on the web.

Edit: Found it!

https://muchosoft.com/products/muchofileinfo/

You're welcome. 🙂

I'd be interested in knowing if any of these files still retained their Type/Creator codes. You can copy/paste the code just above your last post into the Script Editor found in the /Applications/Utilities/ folder. Just paste and click the run button (arrow). Select a file and see what it returns.

For either without a code, it will say "missing value". Otherwise, a Word document should have a Creator code of MSWD, and a Type code of W8BN.

What kind of files are they?

Safe Boot from the HD, (holding Shift key down at startup), does the problem occur in Safe Mode?

Safe mode attempts to repair Disks & clears lots of caches, so if Safe Mode works try again in regular boot.

Me cheat. Me find code online (and modified it to simplify). 😁

set selectedFile to (choose file)
tell application "Finder"
	set fType to the file type of selectedFile
	set cType to the creator type of selectedFile
end tell
display dialog "Creator: " & cType & return & "Type:      " & fType with title "File: " & selectedFile

Yeah, that's where I started, but I have so few classic Mac OS original files now that testing is frustrating. Here is another variation:

set infile to POSIX path of (choose file default location (path to desktop))

set creator_code to "n/a"
set type_code to "n/a"
set codes to {} as list

tell application "Finder" to set fname_ext to (POSIX file infile as alias)'s name
try
	set codes to words of (do shell script "mdls -raw -name kMDItemFSCreatorCode -name kMDItemFSTypeCode " & infile & " | xargs -0 -n 2") as list
end try

if (count of codes) > 0 then
	if not (item 1 of codes) = "" then set creator_code to (item 1 of codes)
	if not (item 2 of codes) = "" then set type_code to (rest of codes)
end if

display dialog "Creator: " & creator_code & return & "Type:      " & type_code with title "File: " & fname_ext
return

It keep getting a 0, or lengthy integer back from my old image files, so maybe I need to convert the integer to a hex string? Still working on this animal. The file attributes actually show 0 or a floating point number for these codes, which makes it even more fun to deal with.

Duh! I did what the message said to do and compiled the code. Then saved a .app file. But as expected, it returns n/a for the codes.

Other than that, I haven't coded anything since Turbo Pascal for DOS. 🙂 I'm afraid I can't be much help figuring this out.

No problem. I was just curious to find out of any of the "Exec" files had carried over their Type/Creator codes, or if those had been lost, too.

Very good to hear though that you seem to have gotten all of them to open.

I think I am done with this distraction. 🙃

Quitter! 😀

Thanks for trying. 🙂