Cannot save new patches MacOS 10.14 Rack2 Free

Open a terminal and go to the directory where the problem patch is, e.g. cd ~/Documents/Rack2/patches/Noodlings/, and post the output of running the command ls -ln "problem patch.vcv". Also post the output of running the command id in your terminal.

Try the same as above…

susachev@susachev-macbookpro1:~/Documents/Rack2$ ls -ln template.vcv 
-rw-r--r--  1 273201  89939    18B  5 Dec 12:25 template.vcv
susachev@susachev-macbookpro1:~/Documents/Rack2$  id -G
89939 90128 93719 90673 82193 92278 94344 77056 91674 93214 94342 66688 90321 83042 90899 90535 89266 94278 86931 94339 93743 96089 90415 92188 92930 90578 94343 77506 87815 94340 90387 94376 81910 91750 89971 87465 97231 90558 85841 95521 70967 81448 94333 93858 94341 79910 90537 82189 90518 96853 91675 94191 92741 94338 94083 82712 77281 88414 97552 91199 87253 12 20 61 80 81 98 398 399 86035 93368 89046 94331 82072 980 83243 94336 80665 87558 92487 74990 5000 84796 94332 90384 94337 78931 91041 94335 70970 87986 91767 97644 96792 94334 79982 73208 75209 90338 981 86343 90968 94330 91952 33 100 204 250 395 400

(I don’t want to share group names)

What might be interesting is that all group IDs fit into a 6-digit octal, but the user ID doesn’t, it needs 7.

273201 89939 template.vcv

I’ve never seen user id’s and group id’s that high, looks crazy. Are you on some massively multi-user system?

That user-id of 273201 puts it outside of 16-bit range. I didn’t know that was even legal in POSIX. Looks very weird to me…

Could you post the output of id please, and just replace the group-names with X or something? I would like to see what your id and group number is. Did you make this template.vcv patch on your own system with your own user? Do all your patches look like this, with these high user-id/group-id numbers?

Yes, my user ID is 273201 and my [primarygroup] ID is 89939. Excerpt:

susachev@susachev-macbookpro1:~/Documents/Rack2$ id
uid=273201(susachev) gid=89939(primarygroup)  <...>

Normally, all the files I create and operate on have these UIDs and GIDs.

Are you on some massively multi-user system?

Sort of. While my Mac itself is not massively multi-user, it is integrated with a much larger namespace, so that might be the reason my user ID is higher than 18 bits.

1 Like

I’m getting the sense that this explains it. My sense is that the trouble is in how Rack uses libarchive to write patches. If it actually uses the old “ustar” format, and I’m reading this correctly, there’s room for 8-bit uid and gid fields, which is… very small, that would be strange. For your (somewhat extreme) case you actually need 32-bit or character fields to represent your UID and at least unsigned 16-bit (or character) to represent your GID. If you can dig into Rack’s source-code, and see how it uses libarchive, then maybe file a VCV support case.

Relevant issue in libarchive with suggested solution:

1 Like

Report it here

I did.

PS I know VCVRack doesn’t accept pull requests, but changing this line to


works, tested locally that patches are saved and are interoperable with the released build. (Although @Vortico might have his own reasons for choosing ustar specifically, of course).

1 Like

@Vortico possible fix in the post above in case this is a tricky one to fix.

1 Like

Was going to re-edit but thought it would be clearer written as a reply down here.

@LarsBjerregaard It is VCV policy that purchasers of products (which all VST users are) are guaranteed support at even if the issue is a third party module. Support is struggling under the weight of requests but they are working on it.

Ok, well that’s good news I guess, if support can cope with it. All I know is that the OP identified as running Rack Free and I’ve never heard of VCV support for other plugins before, but live and learn I guess. On VCV - Support it says:

For assistance with your VCV account, feature requests and bug reports for VCV products, the VCV Library, and business/private requests, email or use the contact form on this page.

This says VCV products but maybe there’s been a change of policy I haven’t heard about.

I actually have a Pro version, but it is my understanding that bug reports are welcome from all users:

Professional support will not be guaranteed for Rack CE (although bug reports will be appreciated)

I have the same issue with saving patches on Win 10 too, both version Free and Pro. Error message: Archiver could not get next entry from archiver. and could not get system template clearing rack. Unarchiver cannot write file to dir: Can’t write to:\Documents\Rack2\Autosave.

@user403 Could you include the full error messages? I assume, there’s 2 or 3 different errors that you get, right?

2021-12-01_14-34-16 2021-12-01_14-35-59 2021-12-01_14-35-26

1 Like

My very preliminary guess is that your username (and the path to Rack2 folder as a consequence) contains non-ASCII characters, is that true?

I am not sure why exactly it is causing the issue and how to fix it though, but maybe you can try saving your patches in a folder with ASCII characters only as a temporary workaround if that’s the case.

Also, please report the bug here: VCV - Support, the issue seems to be different from the one OP and I are having.

UPD I have thought of another quick workaround – you can move your Documents folder to a different location, say to D:\Documents, see, for example, here.

I have tried to save the patches somewhere else like in my downloads folder but I was able to do it once…already after I was not be able to save it again on the same place. I had not any issue with Rack 1 which still works on the same PC.Is there a possibility to change the path of the Rack 2 folder from myDocuments to another place?

I don’t have the possibility to change the Documents path as this is done per policy.

Well, then we’ll have to wait for a fix from @Vortico, I guess …

Fixed in the just released Rack v.2.0.3

2.0.3 (2021-12-09)

  • Upgrade from ustar to pax tar patch format. Don’t store actual uid/gid, just set to 0.