FileTyping New vs. Old

OK, I’m using the latest Xojo, on a MacOS 10.14, and the disk format to be considered is APFS (not HFS).

Pretend I don’t know anything - I do, but let’s be solution oriented here.

I have a task where I need to write some files and filetype them with a Creator Code and File Type, as they are going to be used on a old OS9 machine and the app (may) depend on them being typed to be recognized.

The client provided me with some files in SIT format which I unstuffed on a HFS drive and moved them to the APFS drive. The icons still showed in the Finder, and in checking the CC and FT using the old FolderItem.MacCreator and FolderItem.MacType, they were still valid.

So I know these old files can exist on a APFS drive and say who they are. So now I need to create some files and type them. I tried the FolderItem properties and they don’t work like that anymore. No surprise. And I don’t want to tell the client to type them himself.

Any suggestions? How can I type these files?

You’re going to have a hard time with this in everything starting when API 2 came about. When FolderItem was upgraded, the new underlying frameworks no longer support type and creator.

The fact that they “work” is that Apple built in a fallback system into the new Uniform Type Identifiers to deal with this stuff, but you can’t use them directly any more.

Moving them to APFS would have stripped them of any resource forks. That might or might not matter.

What about the hidden files? For example, a file called TIGHT KIT may/may not have a companion file named ._TIGHT KIT. You’d never see it in Finder of course.

In this case that actual file DOES have the hidden companion file. And when I move TIGHT KIT to a Windows computer via network, both files get copied, and of course I can see it on Windows. (Do you know how many files like that I delete cause I’m a neat freak?) ._TIGHT KIT is a 82 byte file, and it has the Creator Code and FIleType in it. One wonders if I can create one of those and see what it does.

And I’m happy to learn about a solution if I’m writing to a HFS drive. That’s easy, I can create a disk image in HFS and mount it. Even a C++ solution would be interesting.

It has to be possible - what about writing a ZIP file that has CC and FT support and throwing the data in there?

I hate to break it to you but there’s just no concept of a creator code any more, and there hasn’t been since at least 10.10. If you go back to using an older version of Xojo, the fact that it uses the old APIs means that you’ll get some of this automatic behavior, but it’s also likely that you won’t be able to interact with the files in newer versions of macOS. The isn’t about the drive file system (HFS vs APFS) it’s about what the OS and underlying frameworks do.

Creator and Type codes basically let you create a unique type for your app, but it also allowed you to not have file extensions on your files. Uniform Type Identifiers (UTIs) allow for additional metadata to be stored with your files which identify where it came from and what “type” it is, but also supports a hierarchy system which defines what happens if your app isn’t installed on the users computer.

For instance, let’s look at PDF files. We all know that the Portable Document Format was developed by Adobe back in the early 1990’s, so it’s a good example of how this all works. To get the correct icon the creator of those files had to be set to ‘Acro’ and the type was 'PDF ’ (yup, a space). The big problem was that setting the creator this way lost the original creator if you were creating your own PDFs. If Acrobat Reader wasn’t on your computer, the file couldn’t be opened.

Shortly thereafter the internet “happened” and the world pretty much settled on using file extensions the way Microsoft told them to. But web pages didn’t only rely on extensions, they also used mime-types. (application/pdf in this case).

Apple came up with the UTI system that encompassed all of these needs in one very complicated system. Basically, a file type is a bundle of definitions… OSType (the old 4 character codes), file extensions, mime-types and a type identifier.

If your app ingests adobe PDFs, it is said that your app imports the PDF type. In Xojo, you uncheck the box that says that your app creates these files, set the file extension to pdf, set the UTI to public.pdf and set the role of your app with relation to the type and poof, users can select Open In from the Finder and it magically shows your app in the menu.

On the other hand, if your app creates custom PDF files and you want to have your own icon for them, you need to set the mime-type, extension, parent UTI to public.pdf and the UTI to something like com.myCompany.myApp-pdf. When a file is saved from your app, that metadata is attached. If a user receives a file from your app but does not have it installed, it would fall back to the public.pdf UTI and open it in another app that says it can, like Preview. UTIs allow for a hierarchy of type and functional codes, so since PDFs are basically blobs, the next type up is public.data. That means that any app claiming to import the public.data type could also try to open your file (let’s say a hex editor).

For any files that it encounters that don’t have a UTI, macOS assigns a globally unique dynamic UTI to the file, which even if you were to have two PDFs, their identifiers will still be unique.

TL;DR Apple left the Creator Code on the cutting floor > 10 years ago and the Type code shortly thereafter, so to operate in that realm you are going to need to use an old version of Xojo as well. Just don’t expect it to play nice with modern versions of macOS made 25 years later.

1 Like

Greg - I appreciate the info, but please read my initial post. I’m NOT trying to create files that interact with my program, or any Xojo app, or any MacOS/OSX app.

The files I want to create are intended to make their way to a OS9 machine and work with a PPC OS9 program. They don’t use resource forks, but they do require CC and FT to be associated with them. Of course I could have the client do that manually once the files get to the OS9 machine but I’m trying to avoid that.

As I mentioned, I unstuffed the files given to me on a 10.6 machine, then I zipped them on that machine. Doing a hex dump on the ZIP file, you can see how the Zip file transports the CC and FT information, it uses a __MacOSX folder in the root of the ZIP. Inside that are all the “._” files, which are always 82 byte files and they hold the CC and FT information among other things. Actually it seems that’s all they are doing, and every one of them (except one) is byte-for-byte identical. They all are AIFF files. The different one is the single non-AIFF one, and that just has added info which is likely the icon. But I’m not concerned about icons, I care about the FT and CC.

I’m going to continue investigating.

After investigation, I’d like to change my question a bit (maybe I should be posting another question, but I’ll stick with this)…

The OS9 app I’m targeting requires the main file it uses to be typed (‘DATA’). (Thus my question on trying to type things, or set them up to be “auto-typed” on delivery to OS9.)

Now, on OS9, if you take a untyped file and add to the name “.aif”, it automatically gets typed ‘AIFC’ - at least on my OS9 Mac. Similarly, if you deliver a file onto a HFS disk and you are running OS9, it gets automatically typed ‘AIFC’. I’m sure there are other files that are prestigious enough for this to happen - whoever/whatever is doing it.

Is this behavior hardcoded into OS9 itself, or is there something that can be programmed in OS9 to make it happen to files of your own choosing? Like, my files are .S3P, I’d love it when I deposited them into OS9, they would be autotyped like files that have an .aif file extension to them.

Apple in fact has not removed the Creator code functionality to set and get Creator codes on files. While the Finder in recent macOS versions will no longer respect them, the attributes are indeed set in the file system. And thus, you can copy the files to older Mac OS X versions (and assume OS 9) and they will be respected. I tested it on Monterey 12.6 and it still correctly sets it and retrieves the value.

Here’s the exact MBS Plugins code you can use to do this. Note you’ll need this in a Module, and a Properly called “NSFileManager as NSFileManagerMBS”. Then use it exactly as the old FolderItem.MacCreator functions…

Public Function MacCreator(extends f as folderitem) As string
  if NSFileManager = nil then NSFileManager = new NSFileManagerMBS
  dim n as NSFileManagerMBS = NSFileManager
  dim e as NSErrorMBS
  dim d as Dictionary = n.attributesOfItemAtPath(f, e)
  
  return StringFromOSTypeMBS(d.Lookup(n.NSFileHFSCreatorCode,""))
  
  Exception err
    return "????"
    
End Function

Public Sub MacCreator(extends f as folderitem, assigns s as string)
  if NSFileManager = nil then NSFileManager = new NSFileManagerMBS
  dim n as NSFileManagerMBS = NSFileManager
  dim e as NSErrorMBS
  dim d as new Dictionary
  
  d.value(n.NSFileHFSCreatorCode) = OSTypeFromStringMBS(s)
  call n.setAttributes(d, f, e)
    
  Exception err
    
End Sub

Oh, and here’s the same for MacType:

Public Function MacType(extends f as folderitem) As string
  if NSFileManager = nil then NSFileManager = new NSFileManagerMBS
  dim n as NSFileManagerMBS = NSFileManager
  dim e as NSErrorMBS
  dim d as Dictionary = n.attributesOfItemAtPath(f, e)
  
  return StringFromOSTypeMBS(d.Lookup(n.NSFileHFSTypeCode,""))
    
  Exception err
    
End Function

Public Sub MacType(extends f as folderitem, assigns s as string)
  if NSFileManager = nil then NSFileManager = new NSFileManagerMBS
  dim n as NSFileManagerMBS = NSFileManager
  dim e as NSErrorMBS
  dim d as new Dictionary
  
  d.value(n.NSFileHFSTypeCode) = OSTypeFromStringMBS(s)
  call n.setAttributes(d, f, e)
  
  Exception err
    
End Sub

1 Like

Interesting. I was not aware that was still allowed, but it’s on a file by file basis.

Thanks!