I am developing a cross platform desktop application that works with local files. I am now integrating with onedrive/sharepoint through the Microsoft Graph REST API to open files, modify and upload back. My application required single writer, so in order to protect against concurrent editors, we are utilizing the check out/check in functionality of Microsoft Graph REST API.
For users that have onedrive desktop sync. If they open a document through a local path i would like to identify this file as being onedrive sync'd so i can issue checkout/checkin through the Microsoft Graph REST API. You can see a similar behavior from the office application when opening sync'd file. Although they do not checkout/checkin they do auto save back and retrieve metadata from onedrive based on the HTTP traffic.
So my question is how do i get more details about the file so i can properly make the REST calls? The id/path and the drive id of the item are critical
For Windows, I see there have been new file attributes added in Windows 10 through the GetFileAttributes win32 method. Such as, FILE_ATTRIBUTE_RECALL_ON_DATA_ACCESS. I can't seem to find anything to retrieve drive item id or drive id
For Mac, what are my options on mac?
Related
I need to count the files created by the requesting user in a shared drive. I understand that there is no real ownership concept for files in shared drives. But when viewing the details of a file on the Drive Webapp it shows a field named "Creator", even in shared drives. So this information must be stored anywhere. It is possible to query it somehow through the Drive API?
Currently there is no method to return the creator in Google Drive API at the moment.
This is a product limitation for Google Drive API, this request can be promoted for future development through here.
As an alternative, you can get the creator of a Shared Drive by using the Google Drive audits from the Reports API https://developers.google.com/admin-sdk/reports/v1/appendix/activity/drive#create, however, data retention time for reports is 6 months.
I developed a desktop application that saves projects locally to disk. Each project is a directory that consists out of many files. If certain files are missing the project is corrupt.
I want to add Google Drive support to my desktop application, so the user can load and save projects directly to the cloud. For clarification, the desktop application talks directly to the users Google Drive. There is no 3rd-party webservice involved.
I want to make the installation process as easy as possible for the user. I know the user can generate an API key for his account, but this is to technical for my target audience.
My question is, can I create a Google Drive App that shows up in the market place, that my desktop application can use to access the files on the users drive? Or is the market place meant to be only for 3rd party web-services that can access someones account?
TLDR; I want my desktop application being able to access Google Drive files. Is it possible to create a 1-2 click installation process that my app can access these files? Setting up an API key is too complicated for my users.
I want to make the installation process as easy as possible for the user. I know the user can generate an API key for his account, but this is to technical for my target audience.
First off an API key is only used to access public data. You will need to have your user authorize your application access their google drive account using Oauth2.
You will need to create a project on google cloud console and create Oauth2 credentials which will allow your application to request access of the user.
I want my desktop application being able to access Google Drive files. Is it possible to create a 1-2 click installation process that my app can access these files? Setting up an API key is too complicated for my users.
Its not exactly one click but a user will have to be signed in to their google account and then click the authorize button.
I had a requirement of editing my AWS-S3 uploaded MS Office documents from the browser. So, we created our own WebDAV server on Apache using the httpd extension. Workflow is explained in the below diagram and description.
Now editing is working just fine. My UI Client hits Spring boot API on WebDAV Server. It will copy the abcd.docx -> S3 object to the WebDAV folder let's say var/www/html/webdav. Now the path to a file becomes var/www/html/webdav/abcd.docx. I send file path to UI clients like https://www.mywebdavserverxyz.com/webdav/abcd.txt. I open this document in the local Microsoft office application like :
<a href='ms-word:ofe|u|https://www.mywebdavserverxyz.com/webdav/abcd.txt'>Edit</a>
Now my question is if I want to enable collaborative editing then which options do I have and which one is best? currently, a single user is able to edit the file at a time, for others file is opening in read-only mode.
Co-authoring using WebDAV is not possible.
However, if you modify your WebDAV server to implement shared locks, when the second user goes to edit the document they will receive a message that the document is currently being edited and they can decide to continue editing, once the initial user UNLOCKs the document their changes will be merged into the second users changes (if any).
I might get in trouble for this question. I am willing to re-write it.
I am assuming that most major online storage services such as DropBox, OneDrive, Box, GoogleDrive etc. expose their service to the web via WebDAV. Ok, now my question is for windows client.
How does the client application hook into the windows os, so that it file requests for a file at path: F:\myfolder, etc. map to WebDav service.
I am looking for an overview of the process for how they:
Discover cached files are stale
Discover new folder structures on the server
Map their folders to the NTFS structure, so that standard windows file i/o finds the files
Is there some sort of open source toolware that could be used to connect to a generic webdav service so that we could build our own custom client manager?
In our case, we have files with a geospatial component. So we don't to browse the server by folder structure, but rather with a map interface, and have that as the filter for what gets replicated to the client folder structure. So we are looking for components to re-use.
Write a Windows Shell Namspace Extension. This will give you access to a data folder hierarchy in Explorer that is not based on traditional files. The disadvantage is you will not be able to access the storage on the command-line, only in Explorer.
I want to send info between a desktop/laptop/tablet app and Windows Phone. One possibility is to send data to the SkyDrive account and have the other end pick it up from there. Is this feasible? What I have in mind is the "Windows 8" app running on the desktop, laptop, or tablet allowing the Windows Phone app[s] to send data to its account. Is this possible, such as by providing the Windows Phone app with the Skydrive login info, or...???
From all the other questions you've posted around this query, it sounds like you want to put a mechanism in place to communicate between a Windows 8 app and a windows phone app. I would recommend you look at building a service to handle the communication instead of trying to leverage mechanisms that weren't designed for what you want to achieve.
In direct answer to the this question, though, you can probably achieve it in this manner, but what happens if the user deletes the file you create?
So, SkyDrive is unique to a user, not a device. This means if your application is running on more than one device you can use SkyDrive as a shared, unified storage option. Not just for files but also for application settings. There's an SDK for every platform, not just MS.
Here's what you need to consider.
The roaming API in Windows 8 puts information in a protected area of SkyDrive. As a result, the user cannot delete or screw up the files stored there. To that end, using SkyDrive as a shared location (like you are asking) doesn't have this benefit. The user can screw with your files or delete them - and wreck your app. There is no such thing as protecting your app files in SkyDrive (at this time).
Specifically, to your question:
The authorization model for SkyDrive requires a token that cannot be practically cached for any app. Also, you cannot cache credentials because you never get the credentials in the first place - you only get the resulting token. Listen, you would violate every possible best practice if you //asked// the user for their username and password and stored them. Please do not do this.
The final answer is this: an app on multiple devices can use SkyDrive as a shared storage solution for files and settings (like XML files) - but the developer needs to understand the risk and mitigate that (mitigation might be easy for your app). The user, on every device, would need to sign in and grant each application access to it folders. And, that's it.