13.15 - access to the path is denied - plugins

[GVA]

Hello, after upgrading Launchbox to 13.15 whenever I'm starting the app I'm getting `Access to the path '...' is denied.` error and then LaunchBox shutdowns. I can make it launch once by removing 'Plugins' directory but then it gets recreated and on next try I'm getting the same error.
Has someone seen anything like that? Can I maybe somehow force LaunchBox to not install those plugins? I have never installed any but I guess in 13.15 there are some by default.

On the screenshots the error relates to 'MAME' directory but it happens randomly for any of the default plugins
 

[C-Beats]

Right click your plugins directory and make sure "Read-Only" is unchecked. We have had several people with this folder locked for some reason and I'm not yet entirely sure why...

[BenFuHolo]

Not sure if this helps identify the fault at all, but I was having a similar problem. @C-Beats upon your suggestion I headed on over to the folder to check out if was set to read only, but it's set as per the below and that appears to be pretty normal for a lot of the folders for Windows 11 for me. Unchecking it just get's reverted to back to the same.

 

However, I realized I had starting using google drive to sync and back up my LaunchBox folder and the issue occurred after that. My solution was to delete the plugin folder completely, and then relaunch LaunchBox. LaunchBox recreated the plugin folder, then once in LaunchBox, it told me I needed to update the Dolphin plugin, restarted, and all seems good again.

No idea if it's the same issue but wanted to through it out there in case it helps anyone in anyway.

[radio5]

I'm experiencing this same issue. I'll uncheck "Read-only"  and hit "Apply", but when I open properties, it's still checked. The only way I can get around this is to delete my Plugins folder every time I start LaunchBox.

I'd be very grateful if someone knows how to fix this once and for all.

[AstroBob]

@radio5 sorry to hear you're still experiencing this, may I confirm what version of LaunchBox you are using? This should have been addressed as of 13.16. If you are already on the latest version on it's still happening let us know and we'll see if we can narrow this down.

Cheers,

[radio5]

Hello @AstroBob. Thanks for asking. I'm currently running the lastest version 13.16, but it's been ongoing since 13.15.

[AstroBob]

@radio5 thanks for confirming the version, though can I confirm are getting the same error as the original poster (i.e Access to the path LaunchBox/Plugins/MAME/denied)? Or is yours referring to a different plugin?

Also, where is your LaunchBox directory hosted? Is it on a cloud storage location like Google Drive or Dropbox, or somewhere else?

[faeran]

11 hours ago, radio5 said:

Hello @AstroBob. Thanks for asking. I'm currently running the lastest version 13.16, but it's been ongoing since 13.15.

Also, if you can post the full crash here that would be super helpful.

[radio5]

13 hours ago, AstroBob said:

@radio5 thanks for confirming the version, though can I confirm are getting the same error as the original poster (i.e Access to the path LaunchBox/Plugins/MAME/denied)? Or is yours referring to a different plugin?

Also, where is your LaunchBox directory hosted? Is it on a cloud storage location like Google Drive or Dropbox, or somewhere else?

@AstroBob It's always the Plugins folder. If I delete one plugin and relaunch, the very next one will be the culprit.
My LaunchBox directory is hosted on Google Drive. It's on a local drive and mirrored in the cloud.

[radio5]

6 hours ago, faeran said:

Also, if you can post the full crash here that would be super helpful.

@faeran As soon as I get home I'll post the crash report.
Thanks

[radio5]

@AstroBob, @faeran

Sorry for the delay in getting this log. Life got in the way. Anyway, I've attached it.

 

Thanks

Debug 2024-10-08 10-54-51 AM.log

[faeran]

On 10/2/2024 at 3:03 PM, radio5 said:

@AstroBob It's always the Plugins folder. If I delete one plugin and relaunch, the very next one will be the culprit.
My LaunchBox directory is hosted on Google Drive. It's on a local drive and mirrored in the cloud.

Based on this response, Google Drive is most likely your issue.

See what happens if you completely shut down Google Drive. Do you still receive access denied issues?

[radio5]

On 10/10/2024 at 1:35 PM, faeran said:

Based on this response, Google Drive is most likely your issue.

See what happens if you completely shut down Google Drive. Do you still receive access denied issues?

I believe you are correct. I paused syncing in the Google Drive app, deleted the plugins folder in my local and online builds, and continued to leave syncing paused for a few days. I then resumed syncing in the Google Drive app and haven't had any issues for the last several days. 

[radio5]

I spoke too soon. The issue persists, unfortunately.

[AstroBob]

Hi @radio5 

Thanks for the update. Unfortunately, continuing to host your build on a Google Drive instance will likely continue to yield this type of error. Historically, when LaunchBox directories are hosted in a location where the file system is continuously being modified (e.g., Google Drive, Dropbox, OneDrive, etc.), it can cause all sorts of problems with file locking or can mess up the permissions that LaunchBox needs to run properly.

While you may have seen success in the past with this setup, we’ve never been able to guarantee that it will work 100% of the time. This is because it largely depends on what Windows is doing with those files, and we have no way of knowing when the syncing service is modifying files that LaunchBox requires.

Although this particular error you’re seeing is related to our new plugin .dll files, there have been issues in the past with other file types, such as image files, database files, etc.

I realize this is frustrating, especially since you’ve used LaunchBox in this way without errors in the past. However, this isn’t a workflow we can fully support, as we have no control over what the syncing service is doing with the files that we need access to.

That said, I completely understand the desire to have LaunchBox backed up to a cloud storage solution. I personally do this with Dropbox as well. My suggestion would be to ensure that Google Drive is not running when you are using LaunchBox. As long as syncing is paused while LaunchBox is in use, it shouldn’t have any issues. The conflicts arise only when both LaunchBox and Google Drive try to access the same file simultaneously.

I realise it may not be the perfect solution, but hopefully, this shines some light on the cause here.

Give me a shout if you have any further questions here.

[radio5]

@Astrobob

Wow! Thank you for the thoughtful, detailed response! You didn't have to go the extra mile, but you certainly did with that explanation, and it makes perfect sense. You guys are always super helpful and friendly when it comes to helping out the users, while most companies would just shrug their shoulders and tell you to Google it. It's one of the many reasons I'm always telling my friends and family about LaunchBox.

Buying a premium license was one of the best purchases I've ever made. With all the updates and progress, there are bound to be a few hiccups along the way. I've been looking to get away from Google Drive for a while anyway, so no worries.

Thanks, again

[skizzosjt]

15 hours ago, AstroBob said:

As long as syncing is paused while LaunchBox is in use, it shouldn’t have any issues.

if this is the case, then folks could use LaunchBox's Startup Application feature to run a script that would either pause or exit the cloud syncing service when the frontend boots. Further, resume/start the cloud syncing service upon the frontend's exit.

I don't use any of those cloud syncing tools to test with, but it sounds easy enough.

[AstroBob]

Thanks for the kind words 😊 We certainly appreciate your understanding given that it's not an ideal situation. The goal is that the work we're doing with save management will hopefully help here, as the end goal is to be able to sync saves across your devices, negating some of the need to host instances across cloud sync services.

And I love the idea of the startup/exit script. Hadn't even thought of that but certainly sounds plausible. Great idea!