I've developed an extension for Google Chrome that HEAVILY relies on Google Drive API (the extension is LBTimer, available in Google Chrome web store), to store data in the appfolder, using XMLHttpRequests
Since May, 13th 2015 I'm finding a problem when using the list method.
If I programmatically create a file in the appfolder, I receive the response: 200 OK and the file created. If then I use the list method to list the files in the appfolder, the file just created is not listed. It happened with several files yesterday. This morning, the files were listed normally, but with any file I create today it happens the same (correctly created but not listed).
Three screens follow: the 1st one is creating a test file in the appfolder using the extension's code. the image shows the server response (200 OK, file created). The second screen shows the list request (list all files whose title contains 'test', it should include the file just created). The third screen shows the response from the server (an empty items list).
There is a way to get them listed: If I create a file, it returns (among other data) the file Id. If I make a simple GET request for that Id, then it is listed from then on.
All other methods are working as expected (as usual), but the list method is giving me this problem since yesterday. Since there was no change in the extension's code, I assume there must have been a change in the API code.
Apparently, it was a caching issue in Google Drive, which has been resolved as of May 15th 2015: Google Drive developers community post
Yes, I noticed the same issue from today. I'm using Google Drive Java API to create files in hidden Application data folder (appfolder). Files are created correctly, but "Hidden data size" i 0. I noticed that my files appears after few hours! I reported this issue to Google several hours ago by Google Developers Console, but the issue still occurs. I think more users should do this to get their attention to this critical issue.
Related
I would like to add URL links into a web-based Google Drive folder. Searching online, it appears that this was once possible with files that ended in a .glink extension. I'm looking for documentation on the file format so that I can create them programmatically.
[EDIT] Why do I want to create .glink files? Because I want links (bookmarks, URLs) to be able to appear in my Google Drive web page and to be able to click on them an go to the page. Microsoft OneDrive supports this functionality.
GLINKS Files
The URL link file feature was available due to a workaround with Back Up and Sync before being deprecated with Drive for Desktop. The .glink seems to be patched and no longer available as it was also part of a third party tool no longer available. It seems it now only saves them as .URL and automatically gives it the icon for Google Docs, as it would take it as a simple file with text.
Checking the .url type file of Windows, when uploading to Drive it does not update as it should, even utilizing Drive for Desktop (as an alternative to sync data like back up and sync) the outcome is the one suggested above.
This is the main reason why there is no longer any documentation about the matter, due to this one not being an official feature and being also fully deleted, it can be confirm by the file type available when creating files with the Drive API:
https://developers.google.com/drive/api/guides/ref-export-formats
I would suggest to request a feature to allow this or to provide a new way to store URL links as before or report it to review if possible any references on how it used to work by submitting a feature request or checking the issue tracker about the matter:
https://issuetracker.google.com/issues/new?component=191650&template=824106
You can also add the details of the previous threads or discussions about the GLINKS.
We use the Google Drive SDK to monitor a folder of spreadsheets for changes. When a change happens, we download the file to our servers and convert it to JSON for further use.
Since a file may contain multiple sheets, we go through this process to extract all sheets:
Download the embedLink from the drive#file resource and parse the HTML to extract the gid of each sheet. (Similar to the approach used here.)
Download each individual sheet as CSV by appending ?gid=... to the text/csv URL from the exportLinks field.
Recently we've been seeing 429 Too Many Requests errors, especially if the file gets big enough. According to the API console we're not close to the quota limit, so presumably export links are not counted as API requests, but is rate limited some other way. Exporting the sheet manually – as a different user from the one used against the Drive API – works fine.
Is there a way to find the gid of each sheet in a file without downloading the full embedHTML? If not, is there some way to avoid hitting the download limit?
EDIT: This incorrectly closed issue seems to deal with the problem of finding the gids of a spreadsheet file.
UPDATE: I've worked around this issue by parsing the XLSX export instead of the CSVs. Haven't seen the problem since.
I am a little late to the party, but this is for future readers.
Refer to this answer to know why the behavior #felix mentioned is happening.
I am quoting #chrish from the comments.
WARNING: Web hosting support in Google Drive is deprecated. "Beginning August 31, 2015, web hosting in Google Drive for users and developers will be deprecated. Google Apps customers can continue to use this feature for a period of one year until August 31, 2016, when serving content via googledrive.com/host/doc id will be discontinued."
Also, to know more details on the subject, you can read the article Deprecating web hosting support in Google Drive by Google.
Hope it helps.
I'm Android developer. I'm using Google Drive Java API to access files in hidden Application Data Folder. Since 14 May 2015, LIST method doesn't return newly created files. Also in the Web interface "Hidden data size" is 0.
Files are created correctly (response 200 OK, file created), but I can't list them.
I was using LIST method for 2 years and everything was fine until tomorrow. After few hours files are listed by LIST method, but I want access them immediately after create.
When I save files into visible data folder everything is fine, but problem is with hidden Application Data Folder.
Could you please help me?
Regards
This was a caching issue specifically for App Folder content that affected list queries.
We've rectified the issue so you should no longer see this issue. Thanks for reporting.
Writes were not affected.
Our application needs a full list of the user's files and folders. We use files.list() via the Javascript library (essentially the same code as shown in the official API reference as an example).
We use the "drive.files" scope.
Examining the response to the list, we find that some files are always missing. I did various tests to understand the problem:
The files clearly exist. They show up in the Google Drive Webapp and, if I explicitly request them via ID, I can get them via the API without problems.
It's reproducible, always the same files are missing.
It is not transient. I tried a day after and still the same files are missing. I know of a few strange effects in the API that go away after some time but not this one.
It is not a one time thing (e.g. some weird things went wrong during upload). If I repeat with a completely different Google Account again files are missing. Of a small set of 147 uploaded files in one test 4 are missed by the files.list call, in another test with the same 147 files on another account 23 files are missing.
It only occurs when I use the drive.files scope. If I relax the scope to drive all files are returned. If look at "Details" in the Google Drive Webapp also the missing files are shown as created by our Application. So it does not seem that they lost their origin somehow.
It also occurs when I specify a search query. If I call files.list with a search term "q: modifiedDate > '2012-06-04T12:00:00'" which also should return all files, the same files are missing.
I re-implemented the same thing as pure REST call to the API to rule out that it is an issue with the Javascript library. The error remains.
Update: I could track it down to an issue with the paging and the maxResults parameter. If I use different values the API returns different number of items:
With maxResults=100 I get 100+100+7=207.
With maxResults=99 I get 99+99+28=226.
With maxResults=101 I get 101+101+0=202.
The last result is interesting which gave me a nextLink indicating there are more results but the items array in the last response was actually empty. This alone might indicate a bug.
Still, this only occurs in drive.file scope, the counts are consistent in the full drive scope.
I'd be glad to hear ideas for a workaround. I'm aware of other ways to keep track of the users files, e.g. using the changes feed. I'm using that already but for a specific part in our application I simply need a reliable and complete list of all our application's items in a user's account.
One more note: We had other issues with the "drive.files" scope before (see Listing files with search query returns out-of-scope results (drive.files.list call, using drive.files scope)). This turned out to be an easy fix. Perhaps this issue is related.
Are there any difference in the files belonging to "shared to me" and own files/folders, was the issue for me ?
The way it is presented in Google Drive was not the same result I got when searching without the correct flags.
I found out when I did this file list with all the folders, that I did have to include from where the search scope of files should be.
- Include deleted files
- Include shared to me files
I'm developing an application using the Google drive api (java version). The application saves files on a Google drive mimicking a file system (i.e. has a folder tree). I started by using the files.list() method to retrieve all the existing files on the Google drive but the response got slower as the number of files increased (after a couple of hundred).
The java Google API hardcodes the response timeout to 20 seconds. I changed the code to load one folder at a time recursively instead (using files.list().setQ("'folderId' in parents) ). This method beats the timeout problem but it consistently misses about 2% of the files in my folders (the same files are missing each time). I can see those files through the Google drive web browser interface and even through the Google drive API if I search the file name directly files.list().setQ("title='filename'").
I'm assuming that the "in parents" search uses some inexact indexing which may only be updated periodically. I need a file listing that's more robust and accurate.
Any ideas?
could you utilize the Page mechanism to do multiple times of queries and each query just asks for a small mount of result ?