Bear with me, this is long and complicated, but TL;DR Where does OSX hide extra attributes on files (either on shares or local)?
We are having issues in our Enterprise environment.
We have an Oracle ZFS setup and our OSX machines are SMB mounting the volume.
A user attempted to move a folder between locations and cancelled this halfway through, this resulted in the folder in both locations being greyed out.
In Finder it shows a creation and modified date on the folder of 06/13/1943 06:13:00
From our linux workstations when we stat the file, it shows correct creation and modified dates.
We then touch the file from the linux workstation or an OSX workstation and through terminal we can see the folder and even use the open command on the folder. But through Finder it stays greyed out and unable to be opened. This affected all OSX workstations accessing this file. None of them could see it, but Windows and Linux were fine.
We ended up using the deprecated GetFileInfo and SetFile commands to resolve this.
My question to the community is, where are these attributes being stored, as they were not visible on the file using ls -la or stat. But were there when we looked at it with GetFileInfo. Does anyone know if OSX does some weird Samba caching and stores it on the server? or puts this in a stupid .DS_Store file?
HELP!!! PLZ
Best Answer
OS X has a couple of ways to store its extra metadata on volumes that don't natively support them:
On things like FAT volumes, it'll store the metadata as a separate file with a "._" prefix on the filename, using AppleDouble format. For example, if the original file was "somefile.txt" and you copied it to a FAT32 volume, the data would be copied to "somefile.txt", and the metadata would be saved as "._somefile.txt".
On an NTFS volume mounted over SMB (if certain conditions I don't fully understand apply), it'll store the metadata as NTFS alternate data streams.
I'm not sure if your Oracle server's SMB implementation supports alternate data streams, but my guess is that it does, and the Mac is using them to store extra metadata (and the server is probably storing them as ZFS extended attributes). You could look for them directly on the server, or you might also try mounting the volume from a Windows client and see if streams.exe can see them.