I've seen a few posts about this over the years, but haven't seen a conclusive solution. My particular situation actually might be useful for troubleshooting this for others, as I'm in a multi-computer environment where the problem only happens sometimes. Read on if you like mysteries...
I have 3 DP rigs. Let's call them
Rig A: Monster Mac Pro running DP and all samples on one machine. DP 8.07, Mac 10.9.5
Rig B: Older Mac Pro with second mac pro as VEPro slave, DP 8.07, (Recent upgrade to) Mac 10.9.5
Rig C: iMac with mac pro as VEPro slave, DP 8.07, Mac 10.8.5
Here's what happens. I sometimes need to transfer a project from Rig A (the main rig) to another of the computers so another team member can work on it. The way I've always done this in the past is to open the file in MIDI-only mode from the destination computer (Rig B), remove all unused soundbites, and then Save As on Rig B. However, I found that after upgrading Rig B from 10.8 to 10.9, I now get the infamous "Unexpected end of file (-39)" error, and the operation fails. The full text of the "Additional information" is this:
Where "Projects 2-1" is the name of the remote drive. Unfortunately the message doesn't/Volumes/Projects 2-1/The Affair/Audio/Cues/110/Analysis Files/TA 110 Finale 01_54_56_16_ MZ Files/analysis
Saving in any location on Rig B generates the same error. Changing the file name, as suggested, makes no difference. Interestingly, the following wrinkles are present:
[*] The file opens, saves, closes normally on Rig A
[*]I can perform this operation on Rig C with no issues.
[*] I can copy freely with the finder from any computer to any other computer
[*] I can perform the exact same operation in "reverse", which is to say, if I open the computer on Rig A, then Save As to Rig B via network, it works.
I tried deleting and rebuilding the Analysis Files folder, since it's mentioned in the error. But it's also just the first folder in the hierarchy, so it probably just chokes on the first file it tries to write. I suspected a permissions issue but there doesn't seem to be anything obviously wrong with the permissions. Maybe BSD file attribute flags, which sometimes get changed? That's approaching the limits of my knowledge.
One thing that's strange, is that when I upgraded Rig B to 10.9, I was no longer able to log into Rig A using its full username - I have to use its account short name instead. I've seen this on another computer as well, but haven't seen any explanation for why that behavior changed. It occurs to me that this might be causing some kind of permissions/file access problem?
It's a real head-scratcher, and one that I can only imagine has some kind of low-level thing at its core. Any ideas?
Thanks