metadatas and FileType

Hello, I’m puzzled by what resemble to an odd behavior.
When I run this simple script :

----------------------------------------------------------------
use AppleScript version "2.5" -- Yosemite (10.11) or later
use framework "Foundation"
use scripting additions
----------------------------------------------------------------

property |⌘| : a reference to current application
property NSMetadataItem : a reference to current application's NSMetadataItem
property fileManager : missing value


set fileManager to a reference to current application's NSFileManager's defaultManager()
set p2d to path to desktop as text
set hfsPath to p2d & "ClarisWorks:CWDB:recipes.cwk"
set itsFileType1 to my getFileTypeOf:hfsPath
set hfsPath to p2d & "extract recently added-removed.scpt"
set itsFileType2 to my getFileTypeOf:hfsPath
set hfsPath to p2d & "get size of resources.applescript"
set itsFileType3 to my getFileTypeOf:hfsPath
set hfsPath to p2d & "consulter AAPL.app"
set itsFileType4 to my getFileTypeOf:hfsPath
{itsFileType1, itsFileType2, itsFileType3, itsFileType4}

#=====

on getFileTypeOf:hfsPath
	set aURL to (|⌘|'s NSArray's arrayWithObject:(hfsPath as «class furl»))'s firstObject()
	set nsMetaItem to (NSMetadataItem's alloc()'s initWithURL:aURL)
	set fileType to (nsMetaItem's valueForAttribute:"kMDItemFSTypeCode")
	if fileType is not missing value then
		tell (fileType as real) to set fileType to string id {it div 16777216 mod 256, it div 65536 mod 256, it div 256 mod 256, it mod 256}
	end if
	return fileType
end getFileTypeOf:

#=====

I get : → {“CWDB”, “osas”, “TEXT”, “PLAP”}

I assumed that the late string would be “APPL”.
Is this result normal or am I facing a bug which I ignored ?

Yvan KOENIG running High Sierra 10.13.6 in French (VALLAURIS, France) mardi 11 février 2020 21:41:22

You’re asking the metadata, which is never guaranteed to be 100% reliable, and you’re asking for something that’s long deprecated. Is there some reason you can’t use UTIs?

I was just revising an old script which grabbed the info with System Events and was surprised by the result returned by ASObjC.
The script was supposed to identify Clarisworks documents and there is no UTI for them.

Yvan KOENIG running High Sierra 10.13.6 in French (VALLAURIS, France) mercredi 12 février 2020 09:02:41

Try my script and say as what results you get, please:

set aPOSIXPath to quoted form of (POSIX path of (choose file))
set theUTIs to do shell script "mdls -name kMDItemContentTypeTree " & aPOSIXPath

set theUTIs to paragraphs 2 thru -2 of theUTIs
repeat with i from 1 to (count of theUTIs)
   set item i of theUTIs to word 1 of (item i of theUTIs)
end repeat

return theUTIs

Although they may have no UTI, the dynamic UTI(dyn.a…) they generate is stable, so you can use that. Otherwise I’d keep using System Events.

@KniazidisR

What is your script supposed to teach me ?
It return : {“com.apple.application”, “com.apple.localizable”, “com.apple.application”, “public.directory”, “public.executable”, “com.apple.application”, “public.item”, “com.apple.package”, “com.apple.bundle”}
I know these UTIs for years.
I repeat that I revised an old script identifying Clarisworks documents.
I have hundreds of them and these old ones have no name extension.
I wished to rename them with name extension.
The script met different files. Some of them are compiled scripts, scripts saved as text, scripts saved as applications …

I was surprised by the type returned for the apps because I never saw that before.

As type identifiers (UTI) wheren’t available when Clarisworks was alive, a Clarisworks database is given an UTI built on the fly :
type identifier:“dyn.ah62d4rv4gk8ygz4ekk” which is not really useful. I’m not sure that it would be given the same on your machine.
If I had asked for the creator code, I would have get:
{“BOBO”, “ToyS”, “ToyS”, “ltap”}
which doesn’t help for applescripts and is odd for the application too. It’s supposed to be “aplt”, not “ltap”.

Yvan KOENIG running High Sierra 10.13.6 in French (VALLAURIS, France) mercredi 12 février 2020 12:18:37

I would also have used info for which would have return : file type:“CWDB”, file creator:“BOBO”, type identifier:“dyn.ah62d4rv4gk8ygz4ekk”

Yvan KOENIG running High Sierra 10.13.6 in French (VALLAURIS, France) mercredi 12 février 2020 12:30:26

It should. You might find this informative:

https://www.macscripter.net/viewtopic.php?id=46158

It’s your own fault when you stated that ClarisWorks .CWK files do not have UTIs. Since this cannot be, I concluded that you were getting something else instead of UTIs.

I had to download an example ClarisWorks .CWK file to make sure that, as I expected, this file has 3 UTIs:
{“public.item”, “dyn.ah62d4rv4ge80g75p”, “public.data”}

By the way, you can also download this file to check whether we both get the same dynamic UTI.
It is the first CWK file (“alice_6.2.9_osx.cwk”), downloaded from HERE

No, it conforms to three UTIs. It doesn’t have any, in the sense of a defined one, and hence the system provides a dynamic UTI.

Edit: To be clearer, when we say a file has a UTI, it generally means that the system or some application has defined a UTI corresponding to the file’s extension. A file won’t have have one if its owning application doesn’t define one, as many older ones didn’t, or is missing (and the info isn’t cached).

Yes, thank you for the amendment. It is always better to be more precise. Although I already knew that the files are conforms to UTI, this is useful for site readers.
However, it would be more interesting to me now to find out if we get the same dynamic UTI. Since this is exactly what I do not know yet.

https://stackoverflow.com/questions/8003919/are-dynamic-utis-stable