Find Deleted File in an AppFolder - microsoft-graph-api

How do I find a file that was deleted and had a relative path of /foo/baz.txt?
I am using the /v1.0 endpoint and my app requests the Files.ReadWrite.AppFolder scope. I can access /drive/special/appRoot.
Will /drive/special/appRoot:/search(q='baz.txt') find deleted files?
Will /drive/special/appRoot:/foo/baz.txt:/versionsversions for a deleted file?
There is not a lot of examples (or documentation support) for using AppFolder.

I'm afraid this isn't possible today.
When a file is deleted from OneDrive (either via the Web App or the API), it is sent to the Recycle Bin and held for 30 days (assuming the user doesn't manually empty it of course).
At the moment, it isn't possible to access or restore a DriveItem from a dive's Recycle Bin (this has been discussed but I'm unaware of any ETA). The only way to restore an item today is for the user to do so via the OneDrive Web App.

According to your description, I suppose you want to get a file that was deleted in App Folder.
Based on my test, we can use the following API to get the file in App Folder:
/drive/special/approot:/foo/baz.txt:/
However, if we deleted the file, it will return a 404 status code when we use this API.
We can get the file by using this API unless we restore it in the Recycle bin of OneDrive.

Related

Download File from Dropbox folder in Rails application

I am trying and failing to download a single file from a "open for public" dropbox folder which a 3rd party created for others to use. I am trying to use this within my Ruby On Rails Application (file is changing but folder stays the same all the time).
I want to:
List all files in that public folder
Make sure that there is only this one file
... and this file has the appropriate filename (ending in .xlsx in my case -> an Excel file)
Download the file (e.g. using RestClient gem)
Save as an attachment to a new database record (Record is existing already and is used inside the app)
Thanks for any hints on how to proceed here! I Than plan to update the file with a cron-job daily.
Its kind of an API to the public :-)
Thought there must be a simple gem to interact with dropbox folders but couldnt't find any.
I used Rest-Client to open the dropbox folder and Nokogiri to parse the content but cant work through the glibberish produced. I gave up after an hour of work and decided to ask here!
Dropbox does offer a public Dropbox API, but it doesn't offer an official SDK for Ruby in particular, but you can either use the Dropbox API HTTPS endpoints directly, or via a third party library if there is one that works for your use case.
Exactly how you would accomplish this would depend on the specifics of the scenario so you may want to read through some guides first to get started, e.g.: Getting Started and File Access.
For instance, depending on how you have access to the content (e.g., directly via a folder in a connected account, or via a shared link, etc.) some of the following endpoints may be useful:
https://www.dropbox.com/developers/documentation/http/documentation#files-download
https://www.dropbox.com/developers/documentation/http/documentation#files-list_folder
https://www.dropbox.com/developers/documentation/http/documentation#files-list_folder-continue
https://www.dropbox.com/developers/documentation/http/documentation#sharing-get_shared_link_metadata
https://www.dropbox.com/developers/documentation/http/documentation#sharing-get_shared_link_file
The Dropbox API v2 Explorer can also be a useful tool for trying out Dropbox API calls.

Should I delete uploaded files from the file system on my own?

I have a rails app where the user can upload files. The files get uploaded to an external cloud service by a backgroud jobs. It's vital for my app that the files won't get stored in the file system after they've been uploaded. Not right away, in general -- they must not remain in the file system.
Should I delete them on my own? Or will get deleted automatically?
Also, debugging my app, I noticied this for an attachment params:
[2] pry(#<MyController>)> my_params.tempfile.path
"/var/folders/qr/0v5z71xn7x503ykyv1j6lkp00000gn/T/RackMultipart20181007-10937-3ntmgg.png"
That file gets stored not in "/tmp" but in "/var" and that means that it won't get deleted automatically, right?
Note that I'm not using paperclip for this task.
You are right the files won't get deleted automatically.
You have to delete the file explicitly at some point in time.
It depends how you set it up. If you used Tempfile to save it then yes the files will be deleted when the object is garbage collected. If not then it probably won't be deleted.
If the files get stored on an external service it might be worth setting up ActiveStorage which allows you to directly upload to external storage providers without the file ever touching your server.

Microsoft Graph API SharePoint Files Search

I try to search for files on SharePoint Document Library (e.g. the default 'root'). I created a few test-files by uploading them or create new Office files online and made some search-requests, e.g. https://graph.microsoft.com/v1.0/sites/root/drive/root/search(q='{query}') and until yesterday everything worked fine.
Now I started to edit files on SharePoint or created/uploaded new ones and with this edited or new files, I have the problem that I get no result when I search for them. "old" files, I created when I started I find although, as long as I don't edit them.
To get access I registered an App inside the AAD and gave it the needed permissions (
Sites.Read.All, Sites.ReadWrite.All, Files.Read.All, Files.ReadWrite.All
and a direct access to a specific file with https://graph.microsoft.com/v1.0/sites/root/drive/items/{item-id}/ works also well.
Search will read data from indexed data, but crawling and re-indexing of a library need to take some time. So you the code return null for the new files:
https://graph.microsoft.com/v1.0/sites/root/drive/root/search(q='{query}')
The following code get the library data directly but not based on the indexed data, so it works well.
https://graph.microsoft.com/v1.0/sites/root/drive/items/{item-id}/

Keeping GoogleDrive files in sync with local files

I'm integrating Google Drive into an iOS app with the SDK, (which works great, thank you) and I would like to keep a set of files on Google Drive in sync with files on the device. By this I mean: When a user renames or moves a file on their device, I'd like it to rename/move on the server. If a user renames a folder, I'd like to rename that folder on the server.
With other cloud services that use a path to identify files, I can generate the path to rename or move the files on the server whenever I need them. With Google Drive, this is not the case--I need a file ID to rename or move something. Is there a convenient way to get the file ID from a path? Will I have to store information from Google Drive in my app? Is there a recommended best practice for this situation? Thanks for any help!
As far as I can see, you can keep a list of file ID when initially you insert file into Google Drive. When you insert a file into Google Drive, it will return a file resource which contains the inserted file ID and it doesnt change unless you delete it.

Documents deleted using Google Docs API still visible in Google Drive

I've built an integration using the Google Docs API (using GData) allowing users to create/edit documents from another application. Originally, when documents were deleted we would have them permanently deleted. They were no longer visible in Google Docs or Google Drive. Now when they are deleted using the Google Docs API, they are still present in the list of Documents in Google Drive. When you attempt to follow the link to the document you arrive at the "Sorry, the page (or document) you have requested does not exist." page.
Does Google Drive not honor the actions taken via the Google Docs API? Do I need to delete these documents using both the Google Docs API and the Google Drive API? What if the user has not migrated to Google Drive? Is there a way to tell if the have migrated? Or do I force them to migrate so I can use the Google Drive API to keep their Google Drive clean of these dead documents?
The Drive API and the Docs List API both operate on the same resources so you only have to use one of them (and we recommend the former).
With the Drive API you can trash or delete files. When you trash a file, it will still be listed in Google Drive with a label to mark it as in trash, so that you can still untrash it.
If you want to remove a file completely, you have to use the delete method.
I was having the same problem and I believe this is some kind of caching on the drive UI.
The file does appear to be deleted correctly and is not visible to the drive API.
The orphaned stubs eventually get deleted as the cache is cleared every so often.
I found that by removing the file from the parent and then deleting it meant that it was easier to see what was going on when using the drive UI whilst testing my app.
service.children().delete(folderId=parent_id, childId=file_id).execute()
service.files().delete(fileId=file_id).execute()
I was facing the same problem while using Google Drive APIs. I think when the Delete api deletes the document, their is still some linking with parent folder remains, so the browser renders the document. when I tired to delete the document with below piece of code, it properly works for me.
DriveService.Childern.Delete(parentResId, fileId).Fetch(); // fileId=>ResourceId of document to be deleted
This is a caching issue, the file has actually been removed. If you try to open the file in the Drive UI you should see something along the lines of "Sorry, the file you have requested does not exist."
It will clear itself soon.

Resources