Fetching previous revisions of multiple files via Google Drive API? - google-drive-api

While trying to import some Android projects into Eclipse, I have noticed that every file in the project is 0 bytes after they are imported. These projects are stored on Drive, so there is some chance of reverting them back to the previous version.
Reverting files to previous versions is easy to do when you've got a few files - you simply do it through a browser. However, I have hundreds of files and I need to fetch one revision back for each. I have been able to download a number of files by hand thus far, but there has to be a better way.
I have asked Google support and actually got a response back, but it's clear that there is no built-in functionality to do this. So I have started looking at the Drive API but I can see that there might be a bit of a learning curve.
Wondering if anyone has run into this before? Ideally I would like to identify one folder and for each file underneath, fetch the last version of the file. If anyone has a good approach for this, I would love to hear it.
thanks!

The pseudeo code to do what you want is
# get the id of the folder https://developers.google.com/drive/v2/reference/files/list
fid=file.list(q=title = 'foo')[0]
# get the children of that folder https://developers.google.com/drive/v2/reference/children/list
children = file.children(fid).maxresults=999
# for each child,
for id in children.id
# get the revisions https://developers.google.com/drive/v2/reference/revisions/get
revisions = file.revisions(id)
# iterate, or take item[1] whatever works best for you, and use its downloadUrl to fetch the file
With each call that you make, you'll need to provide an access token. For something like this, you can generate an access token using the oauth playground https://developers.google.com/oauthplayground/
You'll also need to register a project at the cloud/api console https://code.google.com/apis/console/
So ye, it's a disproportionate amount of learning to do something fairly simple. It's a few minutes work for somebody familiar with drive, and I would guess 3 days for somebody who isn't. You might want to throw it up on freelancer.com.

Related

eBay MIP: Delete inventory item

I need to access the eBay Merchant Integration Platform via SFTP. Using the web CSV upload is not an option, because I want to automate the process.
It works as I can upload products, update quantities, prices, and receive offers periodically. However, I fail to delete an inventory item (which is not the same as setting the quantity to 0, which works fine).
I tried to upload my delete-inventory.csv to the store/inventory folder on the SFTP server, but the error message in the response CSV looks as if eBay interprets the file as a 'normal' inventory.csv.
My question is: To which of the folders (e.g. store/availability, store/distribution, store/product) should I upload my delete-inventory.csv if not to the store/inventory folder?
Call me dumb but I'm unable to find it in the docs.
Here's my delete-inventory.csv:
SKU,Action,Channel ID,Format
test-sku,DeleteInventory,EBAY_US,FIXED_PRICE
And here's the eBay response CSV:
SKU, Group ID, Locale, ePID, Channel ID, Item ID, Status, Message Type, Message ID, Message
test-sku,,,,,,FAILED,ERROR,335101,Invalid request for SKU. Atleast one of shipToLocationAvailability or offers is required.
NB: The same happened when I removed the optional columns Channel ID and Format from my delete-inventory.csv or when I played around with optional/mandatory columns. It does not seem to be a syntactical problem.
Thanks for your help!
Reference: https://developer.ebay.com/devzone/merchant-products/mipng/regular/content/user-guide/definitions-delete-inventory-feed.html?tocpath=Managing%20inventory%7CFeed%20definitions%7C_____10
I asked the eBay support and they told me to use the store/deleteInventory folder. This folder had neither appeared in the directory tree of two SFTP clients on two computers nor in the web interface, but after I contacted them, it was suddenly there...
While EBAY MIP is marketed as "easy to use", it is far from being so. If even the sample files contain errors much less a file from scratch.
Uploads are producing error codes that does not even have proper explanations. More over, an upload will produce an error, you have it corrected, then different error message occurs on future uploads.
Today is my second day uploading a test file and I am still not successful.

Model derivative: translation stops at 50%, never fails, never completes

I have a following scenario, 2 revit files, ModelA.rvt and ModelB.rvt. They are cross-referenced together, zipped and uploaded twice under diferrent object key (ModelA.zip, ModelB.zip). ZIP files are identical, very small(4MB) and containing both files. They both are uploaded succesfuly in a loop using:
PUT https://developer.api.autodesk.com/oss/v2/buckets/:bucketKey/objects/:objectName
Files are overwritten with token scope data:write and a post job called with x-ads-force = true in case of model update. Then I call the POST JOB 2x in a loop, once with ModelA.rvt as rootFilename for ModelA.zip and secondly with ModelB.rvt for ModelB.zip. Both post jobs are done sucesfully.
Right after I am getting manifest for both zip files each 10 secs. ModelB.zip is translated 100% in a few secs, but ModelA.zip never finishes (few hours so far), just hangs for no reason. On friday I thought that is just temporary issue, but no it still lasts.
I tried this scenario 3x times, each time with different set of files today and 3 days back. Same result. This one is the easiest one and they are all already present on the cloud. Still have no idea what is going on.
When I list bucket objects, zip files are never present. Another weird thing. Other files with non-zip extension are.
Does anyone have a clue what is causing this, what could be possible workaround? That is serious issue, because it corrupts usability and reliability of the whole API.
The linked revit files need to be in one zipfile with the new v2 API. See this post for more details: http://adndevblog.typepad.com/cloud_and_mobile/2016/07/translate-referenced-files-by-derivative-api.html

How to retrieve a recent list of trashed files using Google Drive API

I have recently deleted quite a number of files in Google Drive, and they were moved to the trash. I would like to permanently delete them, but the files in the Trash can't be sorted by Deleted Date, but only Modified Date (which is not updated upon delete).
Therefore, I would like to leverage the Google Drive API to enumerate the trash and determine the date it was trashed, to find the set of files I would like to subsequently permanently delete.
From what I can gather, there is a file property which indicates if it has been trashed, but not the date.
I tried searching for this answer, but it's not easy to find, if it is possible. Is anyone familiar with this area of the API?
Is there a better strategy than what I am attempting?
Using Todd's detailed answer, I wrote a Python script to achieve this. It's published on GitHub (cfbao/google-drive-trash-cleaner).
E.g. to view items trashed in the last 30 days, run
python cleaner.py -v -d 30
or
cleaner.exe -v -d 30 on Windows
Edit:
Oops! big mistake!
clean -v -d 30 shows you files trashed more than 30 days ago.
If you want to see files trashed in the last 30 days, run clean -v -d 0 and see all trashed files sorted by their trash date.
Or you can modify my script so -d 30 means "in the last 30 days". Shouldn't be too big a modification.
Directly using https://developers.google.com/drive/v3/reference/changes/list, you can retrieve your most recent file/folder changes. This would seem to list those changes for folder movements as well as trashed files.
Getting the data:
Get a page token from - https://developers.google.com/drive/v3/reference/changes/getStartPageToken
Put that token into - https://developers.google.com/drive/v3/reference/changes/list, with page size of 500, includeRemoved on true, and select all fields with the fields editor link button.
You will see no results, because you are using the most recent page token. You need to manually reduce the page token until the returned changes.time is before the desired date range. (There is no filter for this in the query). Once you have established the correct page token, continue with the steps below.
Before Executing, open the Developer Tools (I was using Chrome) and view the Network section
Look for a transfer name staring with "changes?pageToken=...", and select it, copy the Response to Notepad++
Note the nextPageToken field, and update the requested page token, repeating step 5 until the nextPageToken not longer advances.
I used http://www.jsonquerytool.com/ to paste the data from notepad++ and to query out and find the relevant fileids.
Querying the data for IDs (for each of the results returned):
Paste the JSON into the JSON section
Select JSPath Query Type
Use this query to double-check document name ".changes{.file.trashed === true}.file.name"
Use this query to get ID list to keep ".changes{.file.trashed === true}.file.id"
Copy Results to Notepad++
Permanent Deleting
If you have a small amount of FileIDs (< 100), you may wish to manually run them through https://developers.google.com/drive/v3/reference/files/delete, and optionally check them with https://developers.google.com/drive/v3/reference/files/get on each manual iteration.
Automation
Obviously, if you're dealing with more data it would make sense to write a Script or App to accomplish the above. But at least you can see it's possible.

Google Drive watching for new files

I'm considering using Google Drive push notification in order to replace our currently pulling process.
I started playing with it, but I have 2 major problems:
Watching changes:
When watching for drive changes, I get notification with the new change id. But when I try to query it using: driveService.changes().get(changeId), I intermittently get 404. Am I doing something wrong here?
Watching files:
When watching for file changes, in case of a folder, I want to know about new files added to that folder, so I expected that when adding/removing files from this folder, the "x-goog-resource-state" will hold "add/remove" value while "x-goog-changed" will contain "children".
In reality, the "x-goog-changed" does contain "children", but the "x-goog-resource-state" is always "update", and there is no extra information about the added/deleted file.
Regarding deleted files, I know can get it by watching the file once I have it, but is there a way I can get updated about new files in a certain folder?
I was working on a similar project a few months ago. There are two things you can do to monitor changes on Google Drive :
Set Notification Push using : changes().watch()
Set Notification Push using : files().watch()
The 1st case sends you a request for everything that happens on the Drive you are monitoring, with very little information on what exactly has changed.
The 2nd case is less 'spamming', and you get to decide which folder to monitor.
However the tags on the change type are not accurate. when I was using files().watch() I tested all the use-cases, and I compared the headers of each case.
My conclusions are:
for a new file (or folder) creation inside yourfolder (yourfolder/newfile) the headers contain:
'X-Goog-Changed': 'properties'
'X-Goog-Resource-State': 'update'
which is the same when you move a file to yourfolder, or when you start following an existing file in your folder.
you get 'X-Goog-Resource-State': 'add' when you share with a user
as you can see, the header tags are not accurate/unique.
Also, note that the push-notification channel will not send you requests for files inside a folder inside yourfolder (yourfolder/folder/files). And the channel will expire at some point.
If you still have any questions, or want to know how to implement the code, let me know : )

How works chrome.fileSystem.isRestorable?

chrome.fileSystem.isRestorable is a new part of the chrome.fileSystem API and it saif if a file can be restored with its entry or not. I've made many tests but something is wrong, when I tried to do :
chrome.storage.local.get(
["recentFileId1"],
function(recent) {
chrome.fileSystem.isRestorable(
recent["recentFileId1"],
function (isRestorable){
console.log(isRestorable);
});
});
It returns me true, even if the file has been deleted of my computer. recentFileId1 seems like a real id (many numbers and the path at the end, for example FD158F2A41037D17440C025C1CA5FE08:question.txt) and the file's restoration works if the file is still on my computer. When I tried to restore the file with an id of a deleted file it just returns nothing, no error.
So I want to know : did I use this feature wrong or something? It can work if I try to restore and see what is restored (if it returns nothing the file has been deleted), but I don't want to use a hack if the API is available.
Thanks.
This function is currently only available in the dev channel of Chrome, and should be released to stable in version 31.
What you're describing sounds like a bug, please file it at http://crbug.com. We should always return true or false. What the correct behavior in this case should be is not clear.
The intent of this function is to let an app know if it should provide UI to give the user access to previously opened files. If a file is restorable, it simply means the app still has permission to access the file.
We are reserving the right to limit when files are restorable. E.g. we might have an arbitrary upper limit to how many files can be restored, or the access might timeout after a few months, or we may give the user the option of not letting apps restore any files. isRestorable lets you know if access to a previously opened file is still available.
isRestorable is not intended to give information about how accessible the file still is. Local changes can impact this - e.g. the file might be deleted or the OS access permissions changed. It might still be there but be invisible to chrome and the app due to no read access to the containing folder.
Think about a recent documents menu. This could show files which were opened and since deleted. When the app restores a deleted app it would not work and would show an error to the user. At that point the user might go to their recycle bin or git checkout and replace the file.
Or the recent documents menu could just not show files which have been deleted.
Either way your app should not rely on isRestorable as an indication of whether a file entry can be regained and successfully used, you should handle restoreFile not restoring a file and giving an error, and handle access to the file having permission problems.