I did this and no change. I also just upgraded to VCV Rack v2.2.3 and no change.
Can I ask, where did you hear this from? And is “next Rack build” the current version 2.2.3 or a future one?
Next build after that, sorry, should have specified.
That W/a works here still, should I hit it. Still not sure what exactly triggers it. I had logged a bug with VCV and that is what I heard back a couple days back.
I had the same issue - out of nowhere I was getting this error. Deleting the content of my autosave directory fixed it. Thank you!
1 Like
Deleting (or redoing the permissions for) the Autosave folder is only a temporary fix. The permissions are reset to Read Only every time you open a patch, so before you open the next patch you need to reset the permissions to Read and Write. You need to do this every time you open a patch. This is the only fix I have tried that works every time.
The permanent and correct “fix”, on macOS, is: Go to “settings => privacy & security => files & folders”. On the list of apps look for VCV and give it write access to your Documents folder. VCV support says they believe this will be fixed in the next Rack release, so that Rack always will have write access to the Documents folder.
On Windows, you need to go to Settings, then “Ransomware Protection” and “Controlled folder access”, and allow VCV Rack access to the Documents folder. This was actually adressed in the Rack 2.0.4 installer and shouldn’t be an issue anymore.
This doesn’t work for me - the Autosave folder still resets to Read Only.
1 Like
I can’t say, but it might be that the machine needs a reboot before taking effect, and perhaps also one last deletion of autosave. Anyways, that’s what the system setting is for so it’s strange if it doesn’t work.
Do you have any anti-virus products installed on the machine? Is the Documents folder on iCloud, Dropbox or the like?
it’s not the Documents folder, access to that is fine. the only issue is the Rack autosave/modules folder. And yes, VCV emailed me that it should be fixed in next release after current 2.2.3
Well, the autosave folder is the most prevalent symptom, because that’s where Rack writes by far the most often. But the underlying problem is macOS protecting the Documents/ folder, and all its sub-folders, so including Rack2/ and everything underneath, from being written to from applications without authorization. In the name of security.
There could of course be a seperate bug in Rack as well, that is specifically to do with the autosave folder only, on specific systems under specific conditions. Only Andrew knows I guess…
nope, writes to rest of Rack dir just fine, so not that issue as far as I can tell. I have given it access to files and documents, as should be, but I tried even full access for Rack and it still happens, ONLY on autosave/modules folder, not autosave itself. so no app should have full access unless it needs to do a low level backup of all. But given that does not fix it I discount it is MacOS security that causes this, as otherwise I would see it in the whole Rack folder as it is in Documents folder. Does not compute
For what it’s worth, I had this exact problem last night on my Linux system. Something somewhere decided to remove write permissions on the autosave folder. And of course I don’t have any antivirus or anything like that running. I have no evidence, but the most likely cause is VCV Rack itself, or the unzipper it uses for .vcvplugin files. Instead of deleting the whole folder, I did this:
chmod -R +w /home/don/.Rack2/autosave
Then I started Rack again and everything worked fine. And this isn’t the first time I’ve had to do this.
1 Like
Yeah, must be a bug in the archiver then, or how Andrew is using it in Rack. It wouldn’t be the first one.
Hey everyone, check out this commit to VCV Rack’s source code, in particular lines 581…592. This appears to fix the Unarchiver problem. Looks like it will be part of the next release after 2.2.3.
2 Likes
So VCV has reported to me a while back (stated in another thread about this one perhaps) as I had filed a bug on this after I ended up fighting it first few times and narrowed it down to Rack or one of it’s components. Hopefully that will fix it and fix will arrive soon, as I, if I am in a mood to work on some older patches, hit this regularly enough to be annoying and disruptive to any creative endeavor.
1 Like
Yup, looks like it. Strange he has waited so long. Also strange that not everyone suffers from it. Maybe it’s the combo of macOS protection on Documents + this archiver bug.
I encountered it most recently when I downloaded a patch someone else made. My best guess is when someone creates a patch on one operating system, then sends it to someone on another operating system, there is some mixup about the permission flags. When the file is unzipped, it removes write permission, but no bad behavior is apparent at that time. Then the next time you try to do something in the directory, you hit the bug. If this theory is correct, the reason it’s so hard to pinpoint is the bug doesn’t do anything immediately noticeable. It might be hours or days later when you open VCV Rack again that the problem manifests.
1 Like
It’s an interesting theory. Maybe it mostly bit people who use a lot of other people’s patches.
I don’t think that’s it, because I got the error on one of my own patches … I’ve proved to my own satisfaction that this is a permissions issue on Mac OS, relating solely to the Autosave folder. How it happens, IDK lol
And that patch started on your own machine and never left that specific machine?