…and note the picture at the top shows an example of a typical “TEXT” file type. Note also that it shows it as a UTI-Type of EXPORTED.
But, if you have a Xojo project, add a FileType Set to it, and then click the button to ADD A COMMON FILE TYPE in the new File Type Set Editor, and then choose TEXT as the type to add, it creates a new file type just like the picture mentioned above, except this time the UTI-Type is created as IMPORTED.
I’m writing a program that at different times either needs to read existing text files or create new text files of its own.
Which is the correct UTI-TYPE to use, EXPORTED or IMPORTED?
Think of exported as ownership of the file type i.e.: My application creates these unique files. TEXT can be exported but you don’t want your application registered as “the” app to handle TEXT files. So leave it as imported. That is how it was explained to me.
VERY useful commands are
mdimport -d1
tells you what UTI it thinks this file conforms to
mdimport -d2
tells you what meta data is imported for this file
look for kMDItemContentTypeTree to see the hierarchy it thinks this file conforms to
See mdimport -help in Terminal on OS X
Usage: mdimport [OPTION] path
-d debugLevel Integer between 1-4
-g plugin Import files using the listed plugin, rather than the system installed plugins.
-p Print out performance information gathered during the run
-A Print out the list of all of the attributes and exit
-X Print out the schema file and exit
-L Print out the List of plugins that we are going to use and exit
-r Ask the server to reimport files for UTIs claimed by the listed plugin.
-n Don’t send the imported attributes to the data store.
-o path Write the imported attributes to a file, instead of sending them to the server.