The type/creator codes are not part of the file, but are separate “Finder Info” data. Mac file systems (HFS, HFS+ and APFS) store this data along with a file’s data and any forks (e.g. resource fork) that might also be associated with the file.
When macOS saves a file with Finder data, extended attributes or forks to a non-Mac file system (e.g. FAT, or to a network volume), this metadata (along with the contents of any resource fork data that might exist) gets copied to a hidden file that has the same name as the original file, with a ._
prefix.
As a quick demonstration, create a Microsoft Word document and save it to a Mac location (e.g. ~/foo.docx
). Note the type/creator codes on the document:
$ GetFileInfo foo.docx
file: "/Users/.../foo.docx"
type: "WXBN"
creator: "MSWD"
attributes: avbstclinmedz
created: 08/21/2022 18:24:31
modified: 08/21/2022 18:24:31
Also note that there is no corresponding ._
file (actually, no ._
files of any kind) in that directory:
$ ls -la ._*
ls: No match.
That’s because Mac file systems (HFS, HFS+ and APFS) support this data as a native part of the file system and therefore don’t store it separately.
Now, use the Finder to copy that document to a non-Mac volume (I’m using a USB hard drive formatted as exFAT) and repeat the above:
$ cd "/Volumes/David C"
$ GetFileInfo foo.docx
file: "/Volumes/David C/foo.docx"
type: "WXBN"
creator: "MSWD"
attributes: avbstclinmedz
created: 08/21/2022 18:24:31
modified: 08/21/2022 18:24:31
$ ls -la ._*
-rwxrwxrwx 1 ... staff 4096 Aug 21 18:29 ._foo.docx
This ._
file contains the file’s Finder metadata and any resource fork data (and any other forks) that might also be associated with the file. A Mac will know to look for this file, which is why GetFileInfo still works:
You can dump its contents to see what’s inside:
$ hexdump -C ._foo.docx
00000000 00 05 16 07 00 02 00 00 4d 61 63 20 4f 53 20 58 |........Mac OS X|
00000010 20 20 20 20 20 20 20 20 00 02 00 00 00 09 00 00 | ........|
00000020 00 32 00 00 0e b0 00 00 00 02 00 00 0e e2 00 00 |.2..............|
00000030 01 1e 57 58 42 4e 4d 53 57 44 00 00 00 00 00 00 |..WXBNMSWD......|
00000040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000050 00 00 00 00 41 54 54 52 00 00 00 01 00 00 0e e2 |....ATTR........|
00000060 00 00 01 34 00 00 00 b3 00 00 00 00 00 00 00 00 |...4............|
00000070 00 00 00 00 00 00 00 04 00 00 01 34 00 00 00 20 |...........4... |
00000080 00 00 15 63 6f 6d 2e 61 70 70 6c 65 2e 71 75 61 |...com.apple.qua|
00000090 72 61 6e 74 69 6e 65 00 00 00 01 54 00 00 00 10 |rantine....T....|
000000a0 00 00 1a 63 6f 6d 2e 61 70 70 6c 65 2e 6c 61 73 |...com.apple.las|
000000b0 74 75 73 65 64 64 61 74 65 23 50 53 00 00 00 00 |tuseddate#PS....|
000000c0 00 00 01 64 00 00 00 2a 00 00 24 63 6f 6d 2e 61 |...d...*..$com.a|
000000d0 70 70 6c 65 2e 6d 65 74 61 64 61 74 61 3a 5f 6b |pple.metadata:_k|
000000e0 4d 44 49 74 65 6d 55 73 65 72 54 61 67 73 00 00 |MDItemUserTags..|
000000f0 00 00 01 8e 00 00 00 59 00 00 37 63 6f 6d 2e 61 |.......Y..7com.a|
00000100 70 70 6c 65 2e 6d 65 74 61 64 61 74 61 3a 6b 4d |pple.metadata:kM|
00000110 44 4c 61 62 65 6c 5f 6f 66 66 32 74 33 34 64 33 |DLabel_off2t34d3|
00000120 75 74 70 35 6f 37 76 73 77 70 70 66 61 72 68 72 |utp5o7vswppfarhr|
00000130 79 00 00 00 30 30 38 32 3b 36 33 30 32 62 30 39 |y...0082;6302b09|
00000140 66 3b 4d 69 63 72 6f 73 6f 66 74 5c 78 32 30 57 |f;Microsoft\x20W|
00000150 6f 72 64 3b 9f b0 02 63 00 00 00 00 66 9a 4f 18 |ord;...c....f.O.|
00000160 00 00 00 00 62 70 6c 69 73 74 30 30 a0 08 00 00 |....bplist00....|
00000170 00 00 00 00 01 01 00 00 00 00 00 00 00 01 00 00 |................|
00000180 00 00 00 00 00 00 00 00 00 00 00 00 00 09 f2 8a |................|
00000190 e8 14 f6 73 bd 4a 7d d8 21 e3 ac e3 1c 5d ff 2b |...s.J}.!....].+|
000001a0 b6 18 5c 7e 64 9f bf 7a 8a 7b 7a 8f 03 ff 38 03 |..\~d..z.{z...8.|
000001b0 d6 b5 40 7f c9 68 33 2c 8f f6 35 80 70 77 42 5f |..@..h3,..5.pwB_|
000001c0 0d ae 68 66 f7 f1 fe 6e 0b c5 eb 43 7a 50 93 95 |..hf...n...CzP..|
000001d0 bb 40 65 df 61 ee 12 82 f5 77 79 1d a8 ed 86 a7 |.@e.a....wy.....|
000001e0 fa 4d 2c d2 2d 7a 4b 00 00 00 00 00 00 00 00 00 |.M,.-zK.........|
000001f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000ee0 00 00 00 00 01 00 00 00 01 00 00 00 00 00 00 00 |................|
00000ef0 00 1e 54 68 69 73 20 72 65 73 6f 75 72 63 65 20 |..This resource |
00000f00 66 6f 72 6b 20 69 6e 74 65 6e 74 69 6f 6e 61 6c |fork intentional|
00000f10 6c 79 20 6c 65 66 74 20 62 6c 61 6e 6b 20 20 20 |ly left blank |
00000f20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000fe0 00 00 00 00 01 00 00 00 01 00 00 00 00 00 00 00 |................|
00000ff0 00 1e 00 00 00 00 00 00 00 00 00 1c 00 1e ff ff |................|
00001000
Note, among other things, the type/creator fields (WXBNMSWD
at offset 0x32) and various extended attribute names (e.g. com.apple.quarantine
and com.apple.lastuseddate
). In general, it will have all of the file’s content that is not part of the its data fork.
If you use the Finder to copy the file back to a Mac from the non-Mac volume, it will see this file and will use it to re-create the Finder info and resource fork on the Mac volume.
Non-Mac systems can copy this file all over the Internet and this metadata will be preserved as long as the corresponding ._
file is copied with it at all times.
If, however, you were to copy the file without its ._
file (or just delete it), then that metadata will get lost. Which you can demonstrate:
$ rm ._foo.docx
$ GetFileInfo foo.docx
file: "/Volumes/David C/foo.docx"
type: "\0\0\0\0"
creator: "\0\0\0\0"
attributes: avbstclinmedz
created: 08/21/2022 18:24:31
modified: 08/21/2022 18:24:31
Notice how type/creator information is no longer available. MacOS will still be able to associate the document with Microsoft Word because of the file extension, but that will now be the only possible way. (Word will be able to open it because Microsoft doesn’t store document data in the resource fork.)
This, BTW, is why it is recommended you package Mac files using something like a disk image or a zip file. This will ensure that the metadata and resource fork get packaged with the rest of the file. This way, no matter how many times is is copied and moved using non-Mac systems, when a Mac user downloads the package, the metadata will be there.
There are, of course, other mechanisms for packaging info/resource data with files, but most of them are only of historic interest these days (e.g. BinHex, MacBinary, AppleSingle and AppleDouble (macOS’s current system of using ._
files is a variation of AppleDouble).