1

I have some files that are being saved onto a network drive that forces Mac to save the resource fork as a ._ file. This generally works just fine, but, when I look at the same file on a different computer (running the same exact version of Mac OS X) it doesn’t seem to recognize the data in the ._ file: it displays the type as a “unix executable file” and the icon is this:

enter image description here

Any ideas as to why it’s not interpreting the ._ file correctly?

Improve this question
6
  • 2
    Do the data fork and resource fork files have the same owner, group, permissions, ACLs, etc? Are both Macs mounting the network drive via the same protocol (AFP, SMB, NFS, etc.)?
    – Spiff
    Commented Oct 22, 2014 at 0:52
  • Ok I think this might be the cause of the problem actually. This is what ls -Al returns from my computer("maggie" the one that works correctly) -rwx------ 1 maggie staff 4096 Oct 22 11:29 ._test.gp -rwx------@ 1 maggie staff 80896 Oct 22 11:29 test.gp and this is what's returned from the other computer(the one that isn't reading the resource fork properly) alex is the username I use to connect to the server -rwx------+ 1 marge staff 4096 Oct 22 11:29 ._test.gp -rwx------+ 1 alex GBS1\Domain Users 80896 Oct 22 11:29 test.gp both macs use SMB.
    – asdfasdfasdfasdfasdfasdfasdf
    Commented Oct 22, 2014 at 18:34
  • I'm just curious, what app are you running that still uses resource forks? They've been deprecated at Apple since the advent of OS X, like 13 years ago. It seems strange that there'd be any apps still in use in 2014 that would still be using them.
    – Spiff
    Commented Oct 22, 2014 at 19:38
  • I'm pretty certain it's not the app's fault. I think it's because I'm saving files onto an NTFS drive on the network, and so it uses the resource fork as a fallback.
    – asdfasdfasdfasdfasdfasdfasdf
    Commented Oct 22, 2014 at 20:18
  • 1
    I just realized from your solution that your apps/files probably weren't using a resource fork, but they apparently were relying on the "Finder Info" metadata to be correct. In the AppleDouble format, the ._ includes both the Resource fork and the Finder Info. I also see from decoding your Finder Info that QuarkXPress is to blame. Man I hate those guys. They were always such laggards when it came to adopting new Apple technologies, and made many transitions such as the OS X transition really painful. Sad but not terribly surprised that they're still causing pain.
    – Spiff
    Commented Oct 22, 2014 at 22:05

2 Answers 2

Reset to default
2

Ok, so I couldn't figure out why one computer wasn't recognizing the resource fork, but I figured out a solution. All the files that I need to work with are the same type, so I can just manually set the extended attributes for all the files using

xattr -wx com.apple.FinderInfo "58 50 52 4A 58 50 52 33 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00" *.gp

This assigns the creator and file type extended attributes to what they should be, and solves my problem.

Improve this answer
0
1

That ._ file is called a resource fork and it is basically where the icon is stored. Believe me, this kind of issues with Macs & shares is a fairly huge headache. In general, the issue is the connection type from one Mac to another. Meaning, let’s say your share is using AFP (Apple Filing Protocol) and saving the file to a Windows share and another Mac is also using AFP, then they both will see the icon correctly. But let’s say one Mac is connected via SMB (Samba) and the other via AFP and the file is saved; one might be able to see the icon and the other can’t.

The only real & truly stable solution I believe is to adjust the Samba settings on the Windows server to handle extended file attributes. But this might not be a true long term solution if you follow Mac/Windows compatibility things.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .