This is what I did. I have following hierarchy.
Folder A
Folder A\Folder B
Folder A \Folder C
Folder B has nothing in it
Folder C has a file in it which I uploaded through API
I have no problems deleting Folder B but when I delete Folder C. This is the error I get.
{"Google.Apis.Requests.RequestError\r\nThe authenticated user may not have granted the app 1068466789052 write access to all of the children of file 0B6SoKHS5o1IJV0lmV19qYkVWX3c [403]\r\nErrors [\r\n\tMessage[The authenticated user may not have granted the app 1068466789052 write access to all of the children of file 0B6SoKHS5o1IJV0lmV19qYkVWX3c] Location[Authorization - header] Reason[fileAccess] Domain[global]\r\n]\r\n"}
I'm guessing that you are using drive.file scope?
Three thoughts ...
Are you sure that the app that the created the file and folders is exactly the same app that is attempting the deletion?
If the answer to (1) is 'yes', then it's probably a bug. I get a whole bunch of issues with drive.file scope.
As a workaround, try changing to drive scope.
Another bug I've seen is where you try to delete a folder with more than 100 children. Your question says there is only one child file, but there could be more children in trash. The workaround for this bug is to do your own recursive deletion.
See What can cause "The authenticated user may not have granted the app 69xxx995 write access to all of the children of file 0B6Bxxx",?
Related
I'm using Make (formerly Integromat) to remove permissions on Folders, files and subfolders using Google Drive APIs.
When removing permissions on a folder (either through the UI or the API), Google will recursively remove like permissions from any files in that folder and any subfolders. There is naturally a propagation delay whilst this process completes.
So far so good.
Drive will necessarily leave some file and subfolder permissions intact where those permissions were specifically granted on that/those objects. We therefore need to iterate through those files and subfolders, checking for any residual permissions and removing them with the Remove Permissions API.
The problem here is that there is no way to determine whether permission removals are still being processed (propagated) from the parent folder. THe only (crude) way I can think of dealing with this is to introduce a fixed delay time between permission removals. If the delay time isn't long enough, Remove Permissions returns an error when trying to remove a permission which has already been removed.
Has anyone dealt with this in a more effective way?
I shared a folder containing files and subfolders with files with multiple users and gave them edit permissions. One users account has modified the viewing ability(?) of every file and subfolder they had access to. From my account when I open the top level folder I see it empty but I know these files are still there because I own the majority of them and my drive storage amount hasn't changed.
The user claims they have no idea how it happened so maybe that it was an app they unknowingly gave drive access to?
Is there any way I can fix this from the Google Drive web interface? I found Google Apps Scripts has access to the Drive API, should I find a script that can mass change the permissions?
Only the owner can delete the file.
The files were removed from the folder but were not deleted.
Therefore, they take up disk space.
To view files outside the folder, follow these steps:
https://drive.google.com/drive/search?q=is:unorganized%20owner:me
Excuse my bad English
Venca
When I am deleting a file from Google drive which someone else shared with me, it showed me a message like "one removed file is still accessible by collaborators".
It no longer appears in that folder, but will it be shown in "shared with me"? How can I delete it completely?
tl;dr
To completely delete file in gdrive of owner of the removed file:
Search for is:unorganized owner:me
Delete file
Remove it from trash (delete it permanently)
Explanation:
This is a common problem with Google Drive. Files removed from the Shared folder loses the location pointer and stays on the drive of the owner of the file with lost location property (cannot be accessible in standard way as we browse files in Google Drive).
The removed file can be found by searching for it by name or content, or using suggested the search phrase is:unorganized owner:me.
A scenario that commonly causes this problem and fix:
U (as you) and S(someone else) have shared folder with name Cats pictures
U add cat.jpg (and U is an owner of this file then)
S don't like this picture and use option Remove
The message removed file are still accessible by collaborators pops up
File cat.jpg is removed from shared folder Cats pictures
S is happy and never see a cat.jpg in Cats pictures folder
U cannot see this file either in Cats pictures folder but cat.jpg is still on U private Google Drive!
If U search in Google Drive for cat.jpg it find the file, and it location will be - (file lost it's location in folder tree).
The file found by U can be moved to Trash and then completely deleted 🎈
You mentioned you'd deleted the file from Google drive which was shared by someone else with you. After deleting you saw a message that stated, "one removed file is still accessible by collaborators". Perhaps the one who is sharing the file is one of the mentioned collaborators, or depending on how this document was shared, other members of the group.
Hope this helps!
Rename file a number then delete twice or 3 times it won't recognize it I had 6and there gone now
Google Drive has a cool feature: one can add a file or folder from Shared With Me to My Drive.
Then I can delete this file from My Drive in the same manner (note that if I delete shared file in web version it won't go to Trash)
However, I am getting 403 Forbidden error while trying to delete this file using Google Drive API (because of insufficient permissions due to that I am not owner of this file). So, as one can see, this is not a simple Delete request. How can I implement this functionality?
Add to My Drive changes the parents collection for the item in question. To change this, you will want to unparent the item rather than delete.
Use the about.get call to retrieve the My Drive ID, then remove that ID from the list of parents in the file resource for the file/folder. Update the file with the new list of parents.
A late answer, but I ran into this issue too. This happens because the file isn't actually copied, it's the same instance. If you remove it from My Drive, it will be removed from the Shared Drive too. And you may lack permission to remove it from the Shared Drive.
If you want to just remove it from My Drive: click on the file. In the right panel, under Details, there is a list of locations. At least the Shared Drive and My Drive is listed there. Click the X to remove it from My Drive, and it will disappear there while preserved on the Shared Drive.
This is what I found. After removing the parent of an item shared with me, do a sharedWithMe search still return the item, even though the item's parent list is empty.
Here is the code:
string sItemId = (this is the Id of the item shared with me);
string sParentId = driveService.About.Get().Execute().RootFolderId;
driveService.Parents.Delete(sItemId, sParentId).Execute();
var parentList = m_driveService.Parents.List(sItemId).Execute();
At this point parentList.Items.Count is 0.
Now when I search sharedWithMe the item is in the return list.
In my iOS app, when I execute "queryForFilesList" with q="" I get a list of all files and folders on my Google Drive plus shared root folders, but not the files in the shared root folders. If I use Chrome to show shared folders and click on a shared folder, the files in that shared folder are shown correctly. If the owner subsequently adds another file to the folder he is sharing with me, that file then appears in the list of files obtained by the above query. So, the list that is returned seems to depend on "when" the file was shared rather than "if" the file was shared. I think this is a bug so I need a work around. Obviously Chrome is using the work around. Executing the query using Google's "try it now" produces the same result. I've tried using "children.list" with no luck; sharedWithMe with folderId=root returns nothing. Is there an alias for the shared root?
However, while composing this question, I think I discovered a work around. If you use the id of the shared root folder (say 'xyz') and execute a "queryForFilesList" with q='xyz' in parents, all the files in the folder with id=xyz are returned as expected.
sharedWithMe query will not return the files under the shared folders, it only returns individually shared files and folders.
You can additionally query for '<sharedFoldersId>' in parents to list all of the files under a shared folder.
It's not the best practice, but you can use a following query in list reuest to list most of the shared to you files including children and shared by links files and folders, that were viewed by You.
https://www.googleapis.com/drive/v2/files?q=not+'{your_email_address}'+in+owners