I am trying to create folders using google drive API using the scope
'https://www.googleapis.com/auth/drive.file'
Surprisingly, the api allows me to upload multiple files with the exact same title into the same folder. I can even see these duplicate files if I browse over to my google drive in my web browser.
Is there any way I can have the API prevent duplicates in filenames? I could check for a file's existence before uploading another with the same name, but that seems to be a strange way to handle writing to a file system...
"Is there any way I can have the API prevent duplicates in filenames?"
No. In Drive, files are uniquely identified by their ID. Attributes such as name (aka Title), parent directories, permissions, description, are simply attributes. It works rather well.
Remember that Drive is all about synchronisation between devices, eg. your pc, your Android phone, your Chromebook, etc. How would Drive keep track of which file was which if it identified them by name, which will often get renamed. Eg. I have a file called "Foo" on Drive, synced to my Android phone, and I rename that file to "Bar". If title was the identifier, my Android phone would see that as a new file. Because ID is the (immutable) identifier, and title is merely an attribute, Android can update the title attribute without getting confused.
With this 3rd party SDK you can specifically set whether a file should be overwritten or it will cause an exception.
void upload(String filePath, InputStream stream, long size, boolean overwrite);
Links to SDK and Documentation
Related
Is it possible to download a private access file from Google drive via api?
The reason I want this is to prevent people from sharing the download link because I want to provide files for paid customer only.
If its not what are my option to provide file download only for paid customers and preventing them from sharing those download links with others?
You may want to set scopes for your users to restrict the level of access. See Download Files.
Downloading the file requires the user to have at least read access. Additionally, your app must be authorized with a scope that allows reading of file content. For example, an app using the drive.readonly.metadata scope would not be authorized to download the file contents. Users with edit permission may restrict downloading by read-only users by setting the viewersCanCopyContent field to true.
You may also want to look at Files especially the viewersCanCopyContent.
viewersCanCopyContent
boolean
Whether users with only reader or commenter permission can copy the file's content. This affects copy, download, and print operations.
Lets say I have a web URL to a file on a cloud storage (like Dropbox, Google Drive, etc). How do I convert that to the corresponding file path on my pc? On Android? On iOS?
Assuming of course I have the utilities/apps installed locally.
EDIT: I interested in file name the reverse direction too. (I.e. when I have the local file path, what is the web path?)
EDIT 2: #Greg just made me realize that the problem with file name is much worse on Google Drive than on Dropbox.
And that is very bad. :-(
The reason? Google has good search capabilities on Drive and therefor I and many, many others have put their documents on Drive. However, once I found it I must locate it on my on computer/device. (If I want to edit a pdf for example.)
EDIT 3: #Dan McGrath kindly asked what parts remain unsolved.
Short answer: All. ;-)
Long answer: My actual use case, see below.
My actual use case is a Zotero web app. Zotero is a reference database where you store references to scientific articles, web pages, etc. The items stored in Zotero may include PDF files or - which I prefer - links to PDF files.
I just want to be able to easy access (read) this PDF files from any computer through the web app. And on my own computer I want to be able to edit the files with my local PDF editor. (Be it Android, Windows or whatever.)
By using a cloud storage I do not have to download/upload the files myself. The cloud storage takes care of that part.
For the "reverse" scenario, that is, you have a file and you want the Dropbox shared link, you can use this API endpoint, assuming you're connected to the account via the API:
https://www.dropbox.com/developers/core/docs#shares
I am building a chrome app for Digital Signage where I need the user to select some files from a particular folder (preferably in the app's directory) i.e audio, videos, photos which should be created by the app on install.
The sample code provided by Google requires that the user navigates to a folder like this
chrome.fileSystem.chooseEntry({type: 'openDirectory'}, function(theEntry) {
if (!theEntry) {
output.textContent = 'No Directory selected.';
return;
}
// use local storage to retain access to this file
chrome.storage.local.set({'chosenFile': chrome.fileSystem.retainEntry(theEntry)});
loadDirEntry(theEntry);
});
However, my app simply needs the name of files in that (say Video) known directory for the user to build a playlist, rather than actually selecting a video file.
Is this supported in chrome.fileSystem API? Any pointers to how I cold get this done?
It sounds like you should be using either the app's sandboxed file systems, or the app's install folder itself.
The sandboxed file systems allow the app to store whatever data it wants, in whatever structure it wants. There are two to choose from: persistent or temporary. Temporary may be cleared at any point in time. To use these check out this article. Some of its code may be out of date with the spec. Note also apps need to request the unlimitedStorage to use these.
The install folder itself can be used in a read only way. To do this you use chrome.runtime.getPackageDirectoryEntry.
We are having issues where sometimes a file that a user can access is not returned when the user issues a files.list. This can happen in many ways. For example, new members of a Google group will not see previously shared files, as described in this question. Moreover, acording to Google documentation there are other limits on sharing which can prevent shared files from appearing in the "Shared with me" view. Finally, a user can issue a files.delete on a file she doesn't own, and the file will disappear from files.list but will still exist.
What can a user do via the SDK alone to cause a file which she can access via files.get to appear in the list of files retrieved via files.list? We are using a service account which impersonates users; the user never authenticates to Google via a browser. A link in an email that the user needs to click won't work for us, unfortunately. Accessing the file via the Google Drive UI has the desired effect, but the analogous files.get call does not.
The Google Calendar API explicitly exposes a CalendarList interface where a user can issue an insert to add an existing calendar to her list. The Google Drive SDK seems like a hybrid Files/FilesList interface with some of the functionality missing (nothing like FilesList.insert) and some of the functionality mixed together (issuing a delete as a non-owner acts like FilesList.delete but issuing it as the owner acts like Files.delete).
If we can't manage the user's files list programmatically then it is not useful for our service. We could ignore the files.list call entirely and just start recursively performing children.list queries on all shared folders, but this is incredibly expensive (unless someone knows how to issue a single query which returns all the Files resources in a folder and not just the IDs of those resources).
Any help would be appreciated. We've been trying this many different ways and have been frustrated at every turn. Thanks!
We picked a random file suffix (.mxe) to use with our applications files in Google Drive, but we noticed that many other applications don't show a suffix and open from drive correctly.
If the user removes the suffix in the save dialog, Drive doesn't know how to open it. So, we could add this in the back-end each time, but it just looks better in the Drive listing to have no suffix.
I've got "mxe" listed as the Default File Extensions in the Drive SDK console. If I remove that, will Drive then base the decision which app to open the file with based only on the creating application ID?
If I do that, will the files with the .mxe suffix still open correctly?
You can associate suffixes and MIME types with your application.
The applications that work fine with files without suffixes have registered MIME types that can be opened with them.
For example, if you are writing an image editor, you should register image/* as supported MIME types and the Google Drive UI will know that images can be opened with your application.
If you are not using a standard MIME type, you can always set a custom one (e.g application/mxe).