When I use own API key, git-annex-remote-googledrive have to authenticate again after few hours later.

[hwiorn]

I can upload data using my own Drive API key.

git-annex-remote-googledrive keep saying git-annex-remote-googledrive setup for authentication after few hours later.

I store and synchronize data between Laptop and Desktop using git-annex.
-J option seems to have a race condition issue, So usually I use default(single thread) uploading, which means really slow.
Sometimes, uploading to google drive failed in progress because of this reauthentication.
This re-authentication is a really annoying.

The key is the same of rclone. But rclone doesn't have this issue.
Usually I don't use this key in rclone while I back up data to google drive using git-annex.

[Lykos153]

Thank you for your reports and sorry for the late reply. Can you start a run with --debug and post the (redacted) result here?

[hwiorn]

Thank you for your reports and sorry for the late reply.

I changed to my main laptop to macbook. So, I couldn't see this issue frequently.
But I can see the phenomenon still every few days at my office and home.
Is this okay?

Can you start a run with --debug and post the (redacted) result here?

You mean I have to run git annex sync --content --debug every time and check the result?
I'll upload the log if I see the issue again.

[hwiorn]

Here is the log which I got the same issue again at my office.
annex-debug.log

I got the same phenomenon and re-configure(git-annex-remote-googledrive setup) on last Friday, and this issue happened today also.

git-annex version: 10.20230407
build flags: Assistant Webapp Pairing FsEvents TorrentParser MagicMime Benchmark Feeds Testsuite S3 WebDAV
dependency versions: aws-0.24 bloomfilter-2.0.1.0 cryptonite-0.30 DAV-1.3.4 feed-1.3.2.1 ghc-9.4.4 http-client-0.7.13.1 persistent-sqlite-2.13.1.1 torrent-10000.1.3 uuid-1.3.15 yesod-1.6.2.1
key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL X*
remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external
operating system: darwin x86_64
supported repository versions: 8 9 10
upgrade supported from repository versions: 0 1 2 3 4 5 6 7 8 9 10

[hwiorn]

@Lykos153 Did you check the log file?

My credential file was ~/annex/.git/annex/othertmp/git-annex-remote-googledrive.token. But it always has been deleted after git-annex enableremote GDRIVE_REMOTE.
Is it correct behavior the credential file deleted after git-annex enableremote?
I read the code of git-annex-remote-googledrive and drivelib. I think drivelib needs the credential file for refresh token(autorefresh).

[Lykos153]

I did, but it was disappointingly inconclusive. I need to add additional debug output to AnnexRemote.

My credential file was ~/annex/.git/annex/othertmp/git-annex-remote-googledrive.token. But it always has been deleted after git-annex enableremote GDRIVE_REMOTE.
Is it correct behavior the credential file deleted after git-annex enableremote?

This is expected behavior. The credentials get absorbed to a file in .git/annex/creds/ from where they are served to the remote by git-annex (you can see that in the logs where it says CREDS). If you specified embedcreds=true, the credentials are absorbed into the git-annex branch of repository itself.

The credentials that you see git-annex handing to the remote (timestamp 2023-06-19 15:57:30.273778) are those that result in an authentication error at 2023-06-19 15:57:30.566113. You could try to manually verify if they indeed work.

I read the code of git-annex-remote-googledrive and drivelib. I think drivelib needs the credential file for refresh token(autorefresh).

It does, but it only uses the credentials provided by git-annex through the protocol. The setup function is the only part of the code to access the original token file.

[hwiorn]

I've digged and tested for a long time. The two things I needed to resolve this issue.

1. Make a new project and don't regenerate API key.
   • If your API key was refreshed once, it will be expired in around ~24H. So you need to make another project.
     • https://stackoverflow.com/questions/30380889/google-developer-api-key-expires-every-24-hours
   • If your project in GCP is old, the expiring policy would be different. Don't use it if you think that is old.
     • This is just my guess. Because my API key expiring peroid(sometimes few hours but usually in 2~3 days) is quite different than in the document.
2. Ensure a "in production" status in your project.
   • Just hitting the "publish" button makes "in production" status in GCP console.
   • This is not written in the rclone use-your-own-client-api-key guide.
   • Default expiring peroid is a week(7 days) in "Testing" status.
   • I found this in rclone forum.
     • https://forum.rclone.org/t/google-drive-cannot-refresh-token-after-a-few-days/22036/18
     • https://forum.rclone.org/t/google-drive-token-expiry/24968/4

I've had no issue with git-annex-remote-googledrive for a month or so on both macOS and Linux machine.

Thank you.