1

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

Gunwalloe
  • 19
  • 1
  • 3

2 Answers2

1

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.

Gordon Davisson
  • 11,036
  • 3
  • 27
  • 33
0

I was getting Jan 24, 1984 3:00A, that's the easter egg (the day the first Mac was sold): during transit time stamp until the transfer is complete (where there was some glitch that didn't autofix that date when the copy was over)

assuming the greyed out folders are top level inside a spedific folder (otherwise, add "-recurse" to gci command and remove "-maxdepth 1" from the find command):

not ADS (on a WinOS machine powershell):

    gci -path 'd:\specificfolder' | % {$_.fullname} | gi -stream *

not AppleDouble (connect to the good specific folder, then the bad specific folder (i.e. bad folder will have "-1" appended), then in terminal):

    rm /Volumes/specificfolder-1/._*  && rm /Volumes/specificfolder-1/.DS_Store

Windows is fine with the bad folders (and sees dates correctly), and you're right about Mac's under the hood unix (or linux) seeing the right date with the ls -la command, and all MacOS see the greyed out syndrome, so it's not specific to the machine that you used to copy type-of-problem (and copying the file in Windows producing a greyed out copy, so WinOS surely knows how to transfer that hidden info!).

So I can only help pinpoint where the problem lies, and agree with your solution (but note that right-click and Get Info or select and command+i hasn't gone away in High Sierra, current OS as of this writing); however, if you have a bunch of folders greyed out: better automate; so, to add something, you could run the following two commands:

    find /Volumes/specificfolder/ -maxdepth 1 -type d -exec getfileinfo {} \; \
    | egrep "directory|created" | sed -e 's/directory: "\(.*\)"/\1/' \ 
    | sed -e 's/created: \(.*\)/\1/' \
    | sed -e 's#/Volumes/specificfolder#/Volumes/specificfolder-1#' > temp.txt


    while read oddline; do read evenline; setfile -d "$evenline" "$oddline"; \
    done < temp.txt
S Hunter Simpson
  • 31
  • 3