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).
Related
While experimenting with Google Drive SDK, I noticed a possibly unwanted behaviour of the Google Drive web interface.
When downloading an entire folder as a zip file, some files within that folder with MIME text/plain appear in the zip with added extension .txt, even if their extension is different on Drive.
For example, I had some .conf and .asc files, which ended being .conf.txt and .asc.txt in the resulting compressed archive, respectively.
The issue seems to exist only when using the "Download zip" feature: if the files are downloaded from the web interface one by one or using the SDK the extension is the original, as expected.
For Windows, you can download all your files from Google Drive, but instead of using the browser,
Go to https://www.google.com/drive/download/
Install Google Drive Sync executable
Log into whichever Google account that has your files
Open Windows Explorer and find where your Google Drive is mapped. You should see an icon like the following:
Double-click the Google Drive icon and navigate to the folder you wish to download. You should see links to your Google files, but non-Google files are downloaded and sync'ed with Google Drive Sync like the following:
Right-click to get the context menu and select the compression program. E.g., I have 7-zip installed, so I selected 7-Zip > Add to "your_file.zip"
This will compress the files without adding any weird file extensions. I haven't tried this on Mac or other compression programs. I believe this should work for any file extension since the files are downloaded to your hard drive.
Note, you can select which folders to sync, in case you have folders that were shared with you. This prevents huge downloads, large sync times and allows you to only download and sync only what you need.
Hope that helps.
The same situation with ZIP archives. I use the usual ZIP scheme to store files, but with a different extension *.tec. Before downloading the archive, Google rigidly renames the files to *.tec.zip!
I don't see any solution other than to programmatically check the files for the "zip" extension and rename them before opening. Of course, it's a problem that my product has to fix Google's bugs, but there it is...
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
Using js file picker to select PDF files from Google Drive.
I'm encountering an instance when the downloadUrl is undefined.
I don't understand what can cause this.
I know downloadUrl can be empty for native Google formats, but these are PDF files.
I'd like to know what scenarios (except native Google formats) can cause an empty downloadUrl.
Thanks
You should use the Drive API to fetch the picked files' metadata in order to retrieve the downloadUrl. https://developers.google.com/drive/v2/reference/files/get
Native Google formats can be downloaded (converted and downloaded) via their exportLinks: https://developers.google.com/drive/v2/reference/files#exportLinks
The response I was receiving was 403.
And the scenario was user accessing "work" Drive (Google Drive for your domain)
Turns out Google Drive for your domain Administrators can restrict the permission to install third party apps.
https://support.google.com/a/answer/6105699?hl=en
User will still be able to allow access for the app and select files. Its just going to fail every time with a 403. Very confusing UX.
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
I am trying to create a file that will open with Lucidchart 3rd party app(already installed on my drive).
I set mimeType, defaultOpenUrl, etc. but the created file has mime-type of the app that created it.
For example if I try to do it from drive api explorer, it will set the mime type to mimeType of explorer app.
Any solutions to this problem?
No, only an app is allowed to create files with that app's app-specific MIME type. You can use the create url from the app resource associated with the app to ask it to create a file. See Apps resource.