Awhile back I was intent on replacing my limited use of a Mac Mini w/ a Raspberry Pi. It’s a long story, but the test did not work out, and then circumstances changed and my initial reason for switching was no longer valid. So I moved back to the Mac Mini.
During the time I was using the Pi, in order to do some things to files on an external drive which involved swapping it back and forth between the Raspberry Pi and my MacBook Air, I changed the external drive format to exFAT. But now that I’m back to all-Mac, I am running into some issues. First, I see all these files beginning with ._ that MacOS evidently created because that’s how it deals with exFAT. In addition, ApolloOne evidently doesn’t like exFAT, as it works fine on both Mac internal drives, but can’t write GPS data to a file on the exFAT drive.
On top of all that, a quick Google reveals many results complaining of problems with exFAT and Big Sur. Both my Macs are on Big Sur.
So I guess while I am chilling today, hoping I have mostly mild reactions to this morning’s vaccination, I’ll have plenty of time to move a bazillion files to a new drive, reformat the original back to APFS, and copy back again.
The ._ files store the extended attributes that macOS creates for the files, since ExFAT does t support them.
I haven’t used it, but there is a utility called dot_clean that can merge that info back into the files (if they are on an Apple file system).
Caveat emptor.
Interesting to note issues with exFAT, as I’ve not had issues with it so far, but then I’m simply using it as a storage drive that rarely has info written to it. Currently have a drive with my music plugged in and it reads fine and I don’t often purchase new music (maybe once a month).
My external USB’s are exFAT formatted as well, purely as I work on Mac and Windows and don’t want the headache of NTFS on Mac, or the limitations of FAT32.
For what you’re doing you can just ignore the ._ files. However, if you use Finder copy to copy the 1/2-bazillion files, you may experience some frustration due to incomplete or aborted copying. When I had to accomplish a similar task (with photos), I ended up using cp in Terminal, which worked flawlessly.
If I weren’t getting errors from ApolloOne (which is using exiftool behind the scenes) I wouldn’t worry. Also, I’m finalizing several Hazel rules using various scripting solutions to move a lot of files around on my hard drive and the exFAT external USB drive. Specifically, these are all images with a lot of metadata. Sometimes I test, and if I need to repeat the test, I copy the files from the external drive back over to the internal drive. That’s going to be an issue if the metadata is scattered to separate files…
