Please describe what you are doing to trigger the bug:
According to the documentation, given a Shared Drive called A Shared Drive and a path within that drive /this/path/is/long, the correct syntax for the path for Duplicacy is gcd://A Shared Drive@this/path/is/long. This is reflected in the web version, which after picking a shared drive with the GUI, will create a configuration entry with the same syntax.
Note that I am using a Google Service Account that has the correct permissions for the shared drive, not the other OAuth token method. This means that there is a hidden ‘My Drive’ area that can only be accessed by the service account.
Please describe what you expect to happen (but doesn’t):
The backup is initialized inside the Shared Drive.
Please describe what actually happens (the wrong behaviour):
The backup is initialized with the path A Shared Drive@this/long/path, that is, a folder inside the service account’s My Drive is created named A Shared Drive@this with the other folders nested inside of it as expected. This is problematic, since then the backups are constrained by the service account’s storage quota, instead of the shared drive’s quota. Plus, that kinda defeats the point of using the shared drive in the first place.
I have found a workaround, which is adding a slash after the @ sign: gcd://A Shared Drive@/this/path/is/long. This will properly backup into the shared drive, in the correct location. So I don’t know if this is an issue with the documentation, or with the path parser. I have observed this behaviour across the web version and the CLI version (compiling from the latest source).