-
-
Notifications
You must be signed in to change notification settings - Fork 4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Google Drive API does not always return permissionIds in files.list request #7853
Comments
Heads up @rclone/support - the "Support Contract" label was applied to this issue. |
We only add rclone/backend/drive/metadata.go Lines 379 to 383 in 7b89735
Perhaps this is the problem? I think the reasoning behind this is that decoded permissions will have everything you need in so only show this if not present. This could be a bit cleverer and only show permisisonIds that aren't in permissions. From the stack overflow post this looks like a bug in google drive (rclone already has quite a few workarounds for them). If you do an Can you do that a few times and see if you can see flakiness? I suggest you pipe it through I didn't see a bug in the google bug tracker about this.
Possibly but depending on exactly what is happening we may not be able to tell the permissionsIds are missing or not. |
I don't have direct access to this environment, but I'll see if I can arrange that test. I corrected my original posting, where I mistakenly said that the permissionIds property was not set in the metadata from rclone. That should have said the permissions property; as far as I know, I don't ever get the permissionIds property in the metadata from rclone, as that wouldn't be helpful for translating to the target backend. If rclone does not receive a permissions property from Google Drive but does receive a permissionIds property, does it fetch the permissions for those IDs so they can be sent along to the mapper? If so, then I think the problem must be that Google Drive will not always provide at least one of these properties so that the permissions can be available for the mapper. Clarifying my suggestion, I'm asking if we can use the absence of both properties as a signal to proactively attempt to fetch the permissions of an object using the Regarding |
@ncw The HTTP response from the test shows the presence of the HTTP Response
|
From a data perspective, it looks like this is another case of permissions not being propagated because they are not set directly on the file (i.e., `"hasAugmentedPermissions": false). So I think things are being filtered out here: rclone/backend/drive/metadata.go Lines 373 to 377 in 7b89735
These being inherited permissions was not my understanding when the issue was raised to me, so I'll pursue it on my end for now. I think it would be helpful to log something (perhaps at the DEBUG level) in this spot so it is clear why permissions are not being propagated. |
Yes it does. The logic is
In the Google Drive API docs it says this about reading
So in some cases the
That makes sense.
I had a go at that here v1.67.0-beta.7971.567fa2514.fix-7853-drive-perms on branch fix-7853-drive-perms (uploaded in 15-30 mins) It will debug
|
@ncw The debug statement works well. Thanks! I think we can consider this issue resolved. |
Great! I've merged the debug to master now which means it will be in the latest beta in 15-30 minutes and released in v1.67 I'll close this for now. |
* master: (133 commits) build: update all dependencies drive: debug when we are ignoring permissions rclone#7853 Add Dominik Joe Pantůček to contributors docs: crypt: fix incorrect terminology operations: rework rcat so that it doesn't call the --metadata-mapper twice operations: ensure SrcFsType is set correctly when using --metadata-mapper onedrive: allow setting permissions to fail if failok flag is set Add Evan McBeth to contributors docs: improve readability in faq fs: fix panic when using --metadata-mapper on large google doc files Add JT Olio to contributors Add overallteach to contributors go.mod: update storj.io/uplink to latest release chore: fix function name in comment build: update issue label notification machinery operations: fix missing metadata for multipart transfers to local disk local: implement Object.SetMetadata fs: define the optional interface SetMetadata and implement it in wrapping backends drive: allow setting metadata to fail if failok flag is set cmd/gitannex: When tags do not match, run e2e tests anyway ...
* github.com:rclone/rclone: (59 commits) docs: fix some comments build: update all dependencies drive: debug when we are ignoring permissions rclone#7853 Add Dominik Joe Pantůček to contributors docs: crypt: fix incorrect terminology operations: rework rcat so that it doesn't call the --metadata-mapper twice operations: ensure SrcFsType is set correctly when using --metadata-mapper onedrive: allow setting permissions to fail if failok flag is set Add Evan McBeth to contributors docs: improve readability in faq fs: fix panic when using --metadata-mapper on large google doc files Add JT Olio to contributors Add overallteach to contributors go.mod: update storj.io/uplink to latest release chore: fix function name in comment build: update issue label notification machinery operations: fix missing metadata for multipart transfers to local disk local: implement Object.SetMetadata fs: define the optional interface SetMetadata and implement it in wrapping backends drive: allow setting metadata to fail if failok flag is set ...
The associated forum post URL from
https://forum.rclone.org
N/A
What is the problem you are having with rclone?
Google Drive does not always return
permissionIds
infiles.list
request. I believe I'm seeing the same issue documented in this StackOverflow topic.Here's what I see in our mapper log when the problem occurs. Unfortunately, I do not have the rclone log, but this logging just prints the raw object received from rclone:
Note that there is no
permissions
property.We enabled verbose logging for a second attempt, but the file wasn't deleted in the target, so it wasn't marked for transfer. But I see this in the rclone log:
When metadata is enabled and a given file does not have the
permissionIds
property set, can we issue a request to get that information for the file in question, thereby working around this apparent API defect?What is your rclone version (output from
rclone version
)Which OS you are using and how many bits (e.g. Windows 7, 64 bit)
Windows 11, 64 bit
Which cloud storage system are you using? (e.g. Google Drive)
Google Drive
The command you were trying to run (e.g.
rclone copy /tmp remote:tmp
)rclone copy Source: Target:
A log from the command with the
-vv
flag (e.g. output fromrclone -vv copy /tmp remote:tmp
)I'll email these separately. Unfortunately, this issue is intermittent, and we saw the issue before enabling verbose logging.
How to use GitHub
The text was updated successfully, but these errors were encountered: