OT question for Mac users - "File can't be copied"

[Fender19]

I've spent many hours lately building, signing and testing plugins on Mac OS and then can't get it out of the computer due to "File can't be copied" error. I'm simply trying to save it to a USB stick (plenty of memory and FAT formatted). It's not all files, just SOME of them and not always the same ones/type. I can move the files around INSIDE the Mac, just can't get them OUT.

I suspect something still has the file open somewhere even though all my apps show closed.

Anyone else come across this? What causes this "Cannot copy file" error and how do you fix it? "Google" hasn't been any help!

[machinesworking]

I'm not a developer, but this is probably a permissions issue. You can change permissions for anything by selecting it and Get Info etc. If you're getting the "File can't be copied" because it's being used by something else logging in and out should do it.

[Rockatansky]

Even with a locked file, copying should not be a problem.
Moving would be understandable, but not copying.
Do you have any virus or malware scanners running? (Yes, they exist on macOS as well.)
Have you tried turning it off and on again, i.e. rebooted?
If you're trying to copy an .app or .vst or .vst3 or any other "file that is actually a folder" type (check by right-clicking, if you see "Show package contents" it's actually a folder) then try compressing it into a .zip file first.
How much do you trust your USB device?
If you've connected the USB drive to your keyboard or screen, maybe try plugging it into the computer directly.

[Fender19]

Even with a locked file, copying should not be a problem.
Moving would be understandable, but not copying.
Do you have any virus or malware scanners running? (Yes, they exist on macOS as well.)
Have you tried turning it off and on again, i.e. rebooted?
If you're trying to copy an .app or .vst or .vst3 or any other "file that is actually a folder" type (check by right-clicking, if you see "Show package contents" it's actually a folder) then try compressing it into a .zip file first.
How much do you trust your USB device?
If you've connected the USB drive to your keyboard or screen, maybe try plugging it into the computer directly.

Thank you for the info and suggestions.

I am doing cross-compiling of AAX plugins between Mac and PC. It seems the problem had something to do with the Pace signatures. Once I signed the plugin on the Mac I could not copy it to PC (where I build my distribution folders). I couldn't even copy it in a zip file. The zip itself would copy but then fail to extract.

Anyhow, I have since switched to a different signing cert and now everything seems to be working. Must have been a corruption somewhere...

[Forgotten]

Have you checked that the Thumb drive is mounted? Could be that you can see it, but if it’s not mounted you can’t write to it.

[quikquak]

Wait, you’re compiling Windows plug-ins on a Mac? How are you doing that? Are you using a Windows emu?
I have found recently that Pace signing does’t like being zipped. I don’t know how they know it as I thought Zip was lossless...

[Fender19]

Wait, you’re compiling Windows plug-ins on a Mac? How are you doing that? Are you using a Windows emu?
I have found recently that Pace signing does’t like being zipped. I don’t know how they know it as I thought Zip was lossless...

I'm compiling Mac OS builds on a Mac and the windows builds on a PC. I then transfer all the Mac files to my PC where I bundle into one zip file for distribution (Mac and PC files are in separate subfolders).

So "zipping" a signed file doesn't work - is that the problem? Customers are reporting "the plugin is not a valid 64-bit AAX plugin" - which means the Pace signature isn't being recognized. How do I fix this?

[quikquak]

I swear it didn’t used to be a problem, but now it is.
I resorted to to using package maker that grabs the plugs directly from the installed folders. The standard package maker still works and it also signs the whole thing with your Apple dev code. You can subsequently zip that package up if you want and it it can still be downloadable and run ok. I would interested to know any other way.

[Fender19]

I swear it didn’t used to be a problem, but now it is.
I resorted to to using package maker that grabs the plugs directly from the installed folders. The standard package maker still works and it also signs the whole thing with your Apple dev code. You can subsequently zip that package up if you want and it it can still be downloadable and run ok. I would interested to know any other way.

I think I have this figured out. If you "zip" together an AAX plugin that was signed on a Mac with an AAX build that was signed on a PC the Pace signatures get corrupted.

What I learned now - and seems to work - is that the Mac files have to be zipped on the Mac - the Windows files zipped on the PC. You can then combine those two zipped files (if desired) along with common documentation, etc., into one delivery file using a top-level zip on either system. That initial "OS-specific zipping" seems to preserve the Pace signatures for the respective OSs.

So the conclusions I've come to is this:

• You have to zip it where you signed it.

• Don't move a signed AAX plugin to a different OS unless you zip it first.

If I still have this wrong - and/or there is a better way - please let me know!

Wow - where's the Tylenol?

[quikquak]

Thanks for looking into this. Did you check the download as well to get how a customer sees it? Because I think I was getting different behaviour from file copying. I just went straight for the installer for new plugins, as some people even seem to get confused by the notion of ‘files’ these days.
They call themselves nerds, when all they can do is click icons!

[Fender19]

Did you check the download as well to get how a customer sees it?

Yes, absolutely! In fact that is how - unfortunately - I discovered the error. I had sent the file to the Senior Editor of an industry magazine and he replied it didn't work. OMG!

Lessons learned every day. Now I have to write it all down so I remember how to do it TOMORROW!

[Rockatansky]

Instead of zipping the .aaxplugin "file", which is actually a folder, why don't you isolate it in a compressed .dmg file, "the Mac way"? You can have signed installers auto-generated with your builds using Apple's pkgbuild, and DMG Canvas has fancy command-line tools that could help you move everything into a good looking, compressed and isolated DMG file.
But somehow I highly doubt that zipping something would screw up signing.
Exactly what tool/s did you use to .zip the .aaxplugin file on the Mac?

[Fender19]

But somehow I highly doubt that zipping something would screw up signing.
Exactly what tool/s did you use to .zip the .aaxplugin file on the Mac?

If a signed Mac OS aaxplugin is zipped on the Mac and a signed Windows aaxplugin is zipped on the PC everything works fine.

What I did wrong
I was transferring the signed Mac aaxplugins over to my PC and THEN zipping them along with the signed Win builds in the same operation (separate Mac/Win folders but under one zip file). Pace apparently sees something in this process as "file tampering" and does it's job by invalidating the signatures.

What I'm doing now (that works)
I zip the Mac aaxplugins on the Mac and the Win aaxplugins on the PC and THEN I move them around, put them all in one top level zip, etc. Apparently zipping the files on the respective OS before handling preserves the Pace signature integrity.

I'm using the OS "zip to file" functions on both Mac and PC. It's convenient, fast and it works.

The lesson I learned from all this is that you have to be careful when distributing Pace-signed AAX plugins. You can't move them around like common files once they have been signed or they can break. This is exactly what Ivan said here and he was 100% correct: viewtopic.php?f=33&t=529016

[Rockatansky]

Pace apparently sees something in this process as "file tampering" and does it's job by invalidating the signatures.

Is there some sort of official statement regarding this? I absolutely believe what you wrote about what happened and how you solved it, but without reading it from Pace/Avid themselves, I somehow can't believe that merely copying an AAX plugin would invalidate its signing. As I already pointed out (and as I'm sure you're aware) an AAX plugin is not just a single binary file like a Windows VST2 dll, but it's actually a folder that contains an entire structure of files and folders. How would a bunch of files that are not actually running suddenly become sentient and invalidate themselves? It's way more likely that copying or moving such an .aaxplugin folder would lose some file properties or hidden files on the way, when moving things from an APFS/HFS drive to a FAT/exFAT drive.

[Fender19]

Is there some sort of official statement regarding this? I absolutely believe what you wrote about what happened and how you solved it, but without reading it from Pace/Avid themselves, I somehow can't believe that merely copying an AAX plugin would invalidate its signing.

Yes it can and Avid is aware of it. I shared all of this with Avid developer support and here is their reply:

"I’ll add some information about how to properly distribute and copy .aaxplugin bundles without invalidating their digital signatures in the next AAX SDK update, and also some strategies for troubleshooting these failures in the field such as using shasum to check whether the bundle has changed in a way that would invalidate its signature.

The cross-OS nature of AAX development, the signature check being within the host application, and the way that users typically interact with plug-in files on their drives are all unique aspects for AAX though."

It's way more likely that copying or moving such an .aaxplugin folder would lose some file properties or hidden files on the way, when moving things from an APFS/HFS drive to a FAT/exFAT drive.

I am aware that aaxplugins are "components" like AU (folders). Yes, moving between OS is likely part of the problem HOWEVER I move the pre-signed files back and forth between OS's during development and there is no problem. The plugins only failed to work when similar operations were done AFTER they were signed.