0

I've come across a scenario in my Windows Store app development that various websites indicate is not possible. Can someone please confirm if the following is possible in a Windows Store app and how it can be done programmatically?

  • User taps on a "Load File" button to load a document, is presented with the standard Metro FilePicker, selects a document, and the file loads into the application for editing. The application somehow saves the path to this file or some other resource that would allow the file to be automatically opened on a future application start.
  • User restarts the application by closing it and then opening it.
  • On startup, the application loads the most recently opened document and automatically presents the user with it for editing again (without having to present the user with another FilePicker). The user makes changes to the document, hits Control + S on the keyboard, and changes are automatically saved to the file.

I have tried this in my current application, but it seems that loading a file path automatically from OneDrive does not work (I get a System.UnauthorizedAccessException: Access is denied.). Online, I've read that including the documents capability (which would allow me access to my OneDrive file) will not allow my application to get approval, and since I need approval, this is not a possibility for me.

Alexandru
  • 12,264
  • 17
  • 113
  • 208

1 Answers1

3

You cannot reconstitute arbitrary for access from a path. You need to hang on to the StorageFile to keep its access. To cache the across sessions use the Windows.Storage.AccessCache classes such as StorageApplicationPermissions.FutureAccessList and MostRecentlyUsedList.

These will let you save the permissions granted by the picker to reuse when the app restarts.

I discuss this in more detail at http://blogs.msdn.com/b/wsdevsol/archive/2012/12/05/stray-from-the-path-stick-to-the-storagefile.aspx

Rob Caplan - MSFT
  • 21,714
  • 3
  • 32
  • 54
  • Rob, why is it that picked files are not automatically allowed for reuse through a path, though? – Alexandru Oct 21 '14 at 03:24
  • And will I be able to automatically save to the same path of a previously opened StorageFile if I stick to using that StorageFile on an application restart, or would I have to present the FileSavePicker? – Alexandru Oct 21 '14 at 03:28
  • So many more questions come up in my mind like...if you reference a file but it no longer exists, and you save it, then what happens? – Alexandru Oct 21 '14 at 03:47
  • Like if I have a StorageFile in my FutureAccessList that I edit and save, but the original StorageFile has changed to be a different OneDrive document the user literally copied and pasted over the original, what happens? Does it overwrite the document? If so, that would be bad, because there would be no mechanism for me to check and see if the file has changed since the last time it was loaded. – Alexandru Oct 21 '14 at 15:53
  • Files are likely not allowed through path because the IStorageFile has a security access token associated with it. It's feasible for them to check to see if your app has any valid access tokens for the path in question, but that would likely take quite a bit of extra work, lots of extra processing each time a file is accessed via path (which is often), and likely also presents a potential security vector. For the other questions, why not give them a try? I wonder if FutureAccessList actually loads the StorageFile if the file does not exist. – Nate Diamond Oct 21 '14 at 19:55
  • @NateDiamond It looks like the way it works is kind of like this: I need to create a GUID for each file I use and save the GUID of the last file used, grabbing and storing files in FutureAccessList by the GUID. If file no longer exists, getting it will throw an exception. If you load a file on startup, therefore, it MUST exist, and you can check to see if the file has changed since you last wrote data to it by saving its last state to the application. – Alexandru Oct 22 '14 at 00:02