No write permission

[Nils89]

How can we add write permmission?

[lahma0]

Unfortunately SX Installer/Tinfoil do not support writing to GDrive as of now (or at least as of a week or so ago). The OAuth token request is hardcoded to ask for read only permissions. Hopefully this will change at some point. I will keep an eye on it and update the app appropriately whenever/if they do.

[Nils89]

Ah ok Stahnke, because in the new 3.0.1 it reads so that you can do this „cloud backup“

„ We also like to point out that 'Cloud Saves' is now possible, you can directly backup/restore your Game Saves to gdrive, or Samba, and unlike 'Nintendo Cloud Save' feature, this works for all your games!“

Maybe you can check this?

[lahma0]

Sorry it took me so long to respond... I really need to check my email more often.. On to my reply:

Ah, very interesting. While I was aware that they added SAMBA support in the last update, I wasn't aware of the 'Cloud Saves' thing. I will definitely poke through the latest update binary to see if I can ascertain what has changed.

If they did change the OAuth token's scope value, then it will be very easy to fix my little utility to create the proper credentials files. In fact, if you are using the Python version of the utility, you can simply change this (line #22): DEFAULT_SCOPES = "https://www.googleapis.com/auth/drive.readonly" To this: DEFAULT_SCOPES = "https://www.googleapis.com/auth/drive" And then run the utility again to create new credentials/token files.

Update: I actually went ahead and poked around a bit in the new binary and it appears that they are still using a hardcoded readonly value for the scopes string. So, if the new version can actually backup save files to Google Drive, then I don't think it is storing them in your normal Google Drive storage folder. Instead what it is probably doing is backing them up to a hidden/isolated storage space that all Google apps automatically have access to (regardless of the app's scope, including readonly). It is typically used by apps as a place to store config files and such and as a result, it is not visible to the user or other apps. If this is indeed the case, then you shouldn't have to change anything, and it should be able to backup your saves to that hidden app-storage area without any modifications.

If you try it out, it would be great if you could report back here what your results are.

P.S. :grey_question:Who is Stahnke:grey_question:

[Nils89]

😃 Stahnke is autocorrection 😃🙈

And thanks for your reply. So means, how do api need to configurate The gdrive Save path to write to the hidden folder?

If I do it with the token, I get the error like „can not rename „gdrive/xxxxxxxx““

[lahma0]

Ya, I actually just tried it and it appears that allowing you to use a gdrive path in the save backup folder field is just an oversight by the developer. My guess that they were possibly backing up to the Google app's isolated storage space was incorrect, so using a gdrive path there will not work until the developer specifically adds support for it. Hopefully they will implement it soon because it would be very useful to be able to directly backup saves to Google Drive. Sorry about that man... Unfortunately there isn't anything I can do about it at this point.

[lahma0]

Got an update on this issue. @blawar was kind enough to chime in on my thread on GBATemp and acknowledged the issue. No timeline, but he did say it will be updated/fixed soon. For more info (including a workaround using nut server for the time being), see my forum thread on GBATemp: https://gbatemp.net/threads/gdrive-token-generator-for-sx-installer-authenticated-google-drive-support.550333/#post-8864949

[Nils89]

Any news with the latest 3.02 version?

[blawar]

should work with 3.02 as long as he is requesting full gdrive access for the token.

[lahma0]

Actually, @blawar sent me a msg not too long ago and said the following:

Please try the latest version of tinfoil and nut, should fix the gdrive write issue. If it works, sx installer should be updated soon.

When I received the msg, I was really busy with a work project. I meant to give the new version a try, but I totally forgot about it until I saw this msg from you, @Nils89 . Unfortunately, I don't have SX OS installed on any of my Switch units anymore, so I'm not sure if I will even be able to run SX Installer. Ultimately though, I don't think it matters much as the code base between Tinfoil and SX Installer should be nearly identical. I will try to load up the latest version of Tinfoil some time today and see if writing to gdrive works correctly now (and whether I need to modify the Token Generator's code and/or documentation).

Have you tried SX Installer 3.02 with and without SX Server 1.21? If so, were you able to write to gdrive (particularly, were you able to backup your saves to gdrive)? It would be super helpful if you could give me a little feedback on SX Installer/SX Server since it is unlikely I will be able to try those out directly. I will let you know what I find out with Tinfoil/Nut (hopefully some time today).

[Nils89]

So I have tested it and it works only with /root if I set the Folder ID I get the error "failed to get Folder id"; "failed to create upload session"; "failed to open wrtire file "

[Nils89]

ok got it, you Need only the Folder Name not the ID: "root/test/" works perfectly :)

[lahma0]

Nice! Glad to see its finally working correctly. It is a little confusing that you use the folder name instead of the folder ID only for save files. Then again, maybe he changed the app to use folder names for gdrive, instead of folder IDs, regardless of where you're using the gdrive path. If you define a new gdrive path under File Browser, does it still require a Folder ID or can you use folder names/paths? If not, do Folder IDs not work at all anymore (i.e. only folder names/paths work now)? I appreciate your feedback man. It is going to be super helpful for updating my documentation.

[Nils89]

So I have test it: For savegames you need the folder name start with „root/xxxxxx“ In the filebrowser you need in the path the folder ID

[lahma0]

Wow... That is super awkward... Oh well. I suppose it will be fixed/changed in a future version. Thanks again for all your help.