The following forum(s) have migrated to Microsoft Q&A (Preview): Developing Universal Windows apps!
Visit Microsoft Q&A (Preview) to post new questions.

Learn More

 locked
[UWP]User Granted Full Access to a Folder Subtree RRS feed

  • Question

  • Please let me know if I'm wrong...

    As best as I can tell, a UWP app cannot ask the user to grant full access to a folder subtree.  By "full access", I mean enumerating, creating, reading, overwriting, replacing, etc, etc, etc, all files and folders from the granted folder on down for the UWP app to manage as it needs.  Probably excluding mucking with security settings for the files and folders. Just the basic file/folder management activity.

    In other words, the same thing a UWP app can do in its sandboxed folders under AppData\Local\Packages, but in another folder subtree the user grants permission to elsewhere on the system.  "Grants permission to" seems like it would be through the FolderPicker.

    It seems like our experience has been (perhaps we're wrong), that a user giving an app access to a folder via the FolderPicker doesn't really grant the app sufficient access to then do everything. I think our experience was the app still couldn't create files in the folder (or perhaps couldn't replace files) without still requiring the user to use the FilePicker.

    We recognize there are a LOT of potential combinations of things we "could" try and spend years experimenting without any assurance of success.  It seems like somebody with a strong working knowledge of the privileges system for UWP apps would just know the answer.  Is it not possible, or is there some approach we haven't thought of.  Something "less than obvious" like maybe we can create a new folder under the folder the user picked via FolderPicker and then we'd have full access to that new folder subtree.

    Okay... why do we need this?  Because we have an app that dynamically manages a large collection of rather large data files for the user.  These are files hundreds of MB in size.  Rather like video files, but they're not videos.  It's entirely reasonable for the user to potentially want those files to reside someplace else other than their system partition.  On notebooks/tablets, it could make perfect sense for them to prefer the data be on a plug-in/add-in flash drive.  Even on desktops they might prefer all that data to be on a secondary drive.

    I realize the app could request full file system access, but we try to be "very good citizens" and squeeze our apps down to the minimum necessary privileges. Our app doesn't need access to the user's entire file system.  It only needs access to some folder subtree the user can grant during configuration and remain denied access to the rest of the user's system. Thus giving users/IT a little extra ease of mind.

    The idea of the Documents subtree will come to mind. However these are pretty big data files and not really "documents".  The user could easily want their "documents" (which likely total a lot less data) to be on their system partition, but not a library of these large data files.


    -- kburgoyne



    • Edited by kburgoyne Wednesday, March 20, 2019 5:40 PM Added Documents folder comment
    • Edited by Barry Wang Thursday, March 21, 2019 5:19 AM title tag
    Wednesday, March 20, 2019 5:35 PM

All replies

  • @kburgoyne,

    Can you be specific about what you have tried, how it failed or even the language you are using? Although we can see your comments "I mean enumerating, creating, reading, overwriting, replacing, etc, etc, etc, all files and folders from the granted folder on down", it seems like storagefile and storagefolder can do this. So if your requirement is more specific, then maybe we can understand it better.

    Best regards,

    Barry


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Thursday, March 21, 2019 7:21 AM
  • Thanks, Barry.

    Our language is C#, but this seems more related to UWP than the language.

    I just wrote a test app, and that app appears to indicate we can manage the entire folder subtree after having the user pick a folder using the FolderPicker. We can even apparently replace files and folders I created using File Explorer and NotePad.  Meaning files not created by our app.

    We did try to do some file overwrites/replacements in our main app earlier in development and ran into problems if the files were not in one of the ApplicationData paths.  Now we're unsure about the difference between our earlier experience and the test app.  We're going to try phasing back into our main app the use of a user-picked folder subtree and see if we can duplicate the test app experience.


    -- kburgoyne

    Thursday, March 21, 2019 3:56 PM
  • @kburgoyne,

    OK. Please feel free to tell us if you have any further question. Also please share us the result if it does work on your side.

    Best regards,

    Barry


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Friday, March 22, 2019 3:13 AM
  • We updated our main app and had success with it overwriting one of our data index files in a non-AppData folder to which the user granted access using FolderPicker.  We didn't have to ask the user for permission to overwrite the file using FilePicker. It's going to take us a while to get around to fully testing with all the other data files we need to manage, but there's no reason to assume they'd act any differently than the index file.

    Testing also indicates this works even if the file being overwritten was not originally written by our app. Presumably normal user access privileges for files would still be enforced by the OS. We didn't see any reason to bother testing to that extreme.

    For us, the user selects a folder as part of configuration/settings using FolderPicker. This is the folder in which our app will manage collections of large data files for the user. Since it's a configuration setting, we use StorageApplicationPermissions.FutureAccessList to get a token for the folder which we save in our configuration settings.  Our ability to manipulate files in the folder does successfully span across multiple invocations of the app.

    We do "default" to a folder we can create in the normal AppData path, but we consider the collection of files to be potentially so large some users might legitimately prefer them to be on a partition other than their system partition.

    I'm giving Barry an upvote on "solution" because his comments are what prompted us to double-check our earlier findings.


    -- kburgoyne

    Friday, March 22, 2019 4:46 PM
  • @barry,

    In a comment which you deleted, you indicated FolderPicker may have granted more restrictive access in the past.  And/or a token for the folder may have had more restrictive access.

    Is that possibly true, or did you delete the comment partially because that might not have been right?  The reason I'm asking is whether there is any potential for being concerned about working on Win10 prior to some given version.  It's the type of thing we should at least know about to properly support our users.

    Thanks.


    -- kburgoyne

    Friday, March 22, 2019 4:51 PM
  • @kburgoyne,

    I delete my last post since that's not right. FolderPicker should be the right way to manage access permissions. I misunderstand your issue and haven't saw that you've already mentioned broadfilesystemaccess capability. 

    So as you've already done, use picker please.

    Best regards,

    Barry


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Monday, March 25, 2019 7:33 AM