Google Drive API - Recovering the original folder for a file restored from trash before the original folder has been restored

1
votes

Scenario

  1. There are many files in a Google (Team) Drive, all of which are nested in folders
  2. All of these folders and their files are deleted by mistake.
  3. In an attempt to recover the data, the Restore button on the Web UI is used
  4. The Restore button in the Web UI does not seem to care about the order, and restores files before restoring the folders that contained them.
  5. Thousands of files end up in the root directory of the drive since their folders "don't exist" when being restored from Trash.

What I need:

How can I recover the information about where the files used to reside, in order to patch this correctly?

What I tried:

  1. Get all of the revisions for one of the files in question with Revisions: list and see there is only 1 result.
  2. Get the revision information for that revision with Revisions: get
  3. Realise that the revision information contains nothing about parents.
  4. Get the file information with Files: get
  5. Confirm that the head revision meta matches the only revision found in step 1
  6. See that the file meta shows the parent is the root.

I can't find a way of determining what the original folder was for the trashed and incorrectly restored file.

1
google-drive-apigoogle-drive-shared-drive

1 Answers

1
votes

After further investigation I don't think it is possible to recover the information about the previous parents from the Google Drive API v3.

However, if you are using Google Team Drive, as part of the G Suite, you should have access to the G Suite Admin SDK Reports API unless you are on a G Suite Basic account. With that you can use Activities: list with various filters to pull back the information about where the orphaned files came from.

I have published my solution here: Google Team Drive Orphaned File Restorer

This console application can pull a list of Google Drive file movements between two points in time, optionally filtered by the IP Address of the user who made the changes (i.e. restored the files from trash). It will then use that information to re-parent the files in question. You can do a dry run to see what the changes will be before you actually commit.