Oh yes, so there is!
It looks like using use_trash makes it work!
I think what I need to do is flesh out a new changes API. The internal API is very crude at the moment so we can't do "invalidate this file ID" even if we wanted to.
Yeah, however, it doesn't solve the actual post issue with the server-side moves, unfortunately.
Looks like the only possible solutions are:
- Redesigned Changes Interface so it can keep track of fileIDs too, for invalidation
- Keep the existing Changes Interface and use the Activity API instead for Drive.
Hopefully, you get the time to do the first choice so it doesn't rely on the specific Drive API to work.
Is the activity API more specific? I thought it would work in place of wherever we are using the Changes interface at the moment, but maybe I missed something?
Not really sure. I haven't gotten around to testing it yet. One issue I did notice while setting it up is that it requires users to enable a different API along with the Drive API on the Google Console. This may cause issues since it won't be a seamless upgrade.
Foo, so it requires a different oauth scope. That is a little bit irritating certainly!
Bad news, this also doesn't handle deletions i.e. it doesn't return the parent IDs for the deleted object. It does handle the server-side moves, however.
Looks like the only option remaining is a file ID to directory ID mapping cache.
On second thought, we can probably walk the activities for an object to get its parent ID, but I am not sure if that is the right approach.
Hmm, well to search for an ID in the VFS cache will either mean building an index or iterating all the items.
Potentially the backend could keep a cache if the last 1000 ID to parent ID mappings.
Did you try the API? The docs lead me to believe that a drive item is returned which should have the parents in it.
Yep, I tested using the API.
Yeah, unfortunately, the definition of a drive item is different for this API: https://developers.google.com/drive/activity/v2/reference/rest/v2/activity/driveitem
Maybe we'll have to try the iD lookup...
This solution would also work but it would require an additional API call for each deleted object. Let me know if that's acceptable and I can try that out too.
Any reason we can't maintain and use a DB for this? It can be one of the purely Golang ones so there are no external dependencies.
An additional API call would be fine.
Caching the state of the remote is a whole different can of worms. I'm planning on doing some of that but at a higher level.
Ok, let me try it out and get back to you. It should be simple enough to do.
Good news, it seems to be working perfectly with a separate golang script locally. I have tested the following and verified that the correct parent directory ID can be fetched for each case to be invalidated:
- Create
- Rename in same folder
- Rename/Move to different folder
- Delete permanently
- Delete to trash
- Restore from trash
Let me know if you want me to try out something else or if I can create a PR for the same once I have done the changes in rclone too.
That sounds great - well done.
A PR would be great.
We'll need to think through asking the user for a new scope but that should be too hard
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.