none
Win32 Store App and LaunchFileAsync "access denied" on URL files RRS feed

  • Question

  • I have a file explorer type app (win32 bridge converted) that is on store and runs fine. 

    The App can also let the user launch document files by the call LaunchFileAsync. This works fine but only for a file type of URL, this gives "access denied" error.

    Suspecting a capability problem, I added broadfilesystemaccess capability in my manifest and then enabled the app in settings for file system access. But the error still appears.

    QUESTIONS:

    1) How can I fix the launching of URL files with LaunchFileAsync that gets "access denied" error?

    2) I'm confused on the capability broadfilesystemaccess. My App is already runFullTrust as it is a win32 Bridge app. Do I still need this capability as a file explorer app? If yes, how can I test what this capability does by doing some action with and without this capability?

    3) What other capabilities does a file explorer app need other than the default capabilities of a win32 bridge app?

    Thanks.


    Sunday, April 12, 2020 6:16 AM

All replies

  • Hi SanjaySk,

    According to your description, it doesn't seem to be the capability issue.There is no direct containment relationship between broadfilesystemaccess and runFullTrust. Could you try to use LaunchUriAsync method to try again?

    Best regards

    Daisy  Tian


    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, April 13, 2020 6:15 AM
    Moderator
  • Hi Daisy,

    I can't find a sample for LaunchUriAsync that accepts a disk file (extension URL) as parameter. That's why I used LaunchFileAsync and that works fine for all files except a URL file.

    Can you give the sample code to use LaunchUriAsync with a URL file (not URL constant)?

    Thanks.

    Monday, April 13, 2020 7:06 AM
  • Still waiting for a solution here. 
    Friday, April 17, 2020 5:00 AM
  • Hi SanjaySk,

    Sorry for the delay reply.Which disk is your URL file in? How did you get the URL file or which app is opened with launch to get the URL file? 

    Best regards

    Daisy  Tian


    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, April 20, 2020 5:45 AM
    Moderator
  • Hi Daisy,

    >>Which disk is your URL file in?

    In desktop folder of the user C: drive. It can be anywhere and
    the same problem comes. I tested that.

    var file = await StorageFile.GetFileFromPathAsync(aFile);
    if (file == null)
      ...return with error...
    
    var result = await 
            Windows.System.Launcher.LaunchFileAsync(file);
    
    
    

    -- Other files are correctly launched, for example, a PDF file in the PDF Viewer.
    -- A False is returned for "not permitted" files like BAT files which is also OK.
    -- The problem is a .URL file that gives an "access is denied" error. It should
    rather return a False if "not permitted.

    >>How did you get the URL file or which app is opened with launch to get the URL file?

    I don't understand this question.

    As I said, my App is a file explorer and the file path is obtained by regular findfirst/next
    win32 calls. Also, the correct behavior is to launch the browser which File Explorer does
    but only because probably it is allowed to use ShellExecute which a Store App can not
    use (specially on Windows 10s). 

    If I use ShellExecute in my App (it's a win32 desktop bridge app), it will work but I 
    don't want to do that as it is not allowed as per the docs.

    Thanks,
    Sanjay
     

    Monday, April 20, 2020 6:28 AM
  • Any progress on this?
    Tuesday, April 28, 2020 1:13 PM