ok thanks! appreciate it.
so. here’s an interesting thing. querying the file UTI on macos:
downloaded with safari:
> mdls -name kMDItemContentTypeTree test-safari.hex
kMDItemContentTypeTree = (
"dyn.ah62d4rv4ge80u3p2",
"public.item",
"dyn.ah62d4rv4ge80u3p2",
"public.data"
)
downloaded with firefox:
> mdls -name KMDItemContentTypeTree test-firefox.hex
KMDItemContentTypeTree = (null)
(besides that, i cannot detect any difference in how the OS sees these files.)
so macos has, by some evil magic, created a UTI association between the file downloaded with safari, and a specific file type. (note that this is not a property of the file itself, they are bitwise identical… which is IMO the ‘evil’ part.)
i assume that this “feature” is recently added to macos/safari, or something.
my safari:
Version 11.0 (12604.1.38.1.7)
my macos:
sierra 10.12.6
the outstanding question is… why the f does the flasher script care about the filetype, as defined by macos UTI? and here i must call a halt to my part in the investigation, having zero experience with that area.
anyways yeah, the workaround is to .zip everything. but its a curious thing that is perhaps worth being aware of. ( perhaps @tehn in particular would like to be aware.)
and maybe i should just say, i guess when i get into “tech mode” maybe it comes off brusquely. and as it happens i have a current professional interest in this (macos item type codes on arbitrary downloaded data files.) i don’t mean to be critical but just trying to cover bases. like you, i spend time on lines for fun and community, and don’t mean to be rude.