none
Open File with _wfsopen that I have access to via FilePicker

    Pertanyaan

  • The User picked a file via FilePicker and I have a 3rd Party app that uses _wfsopen to open files.

    Using the picked file items path property I cannot open the file using _wfsopen. Is there another way to instruct the C-Runtime functions to open such picked files?

    Is there a way to open them via their File Access Broker token?

    13 Maret 2012 16:14

Jawaban

  • Hi Phil,

    Also consider that the StorageFile returned from the FilePicker may not be backed by the file system at all: the user may have selected a picture from another app using the App to App Picking contract.

    As you suggest, if the 3rd party DLL cannot take a stream then you would need to either save the stream to a file or convert it to a buffer. I'd lean towards the in memory buffer, but it depends on the specific needs of the app.

    CreateFile can't be readily hooked for this because the app technically doesn't have permissions to read the file. The "permission" is only at a high level and is handled by letting the broker (which does have permissions to read the file) read it and then hand it over the wall.

    You might also talk to the authors of the DLL to see if they can accept a stream. I suspect they'll need to update the DLL to pass certification for use in a Metro style app.

    --Rob

    • Ditandai sebagai Jawaban oleh phil_ke 14 Maret 2012 7:54
    13 Maret 2012 19:58
  • the library that you are using needs to be updated to use the WinRT stream abstraction, IRandomAccessStream.

    this enables access to "files" stored in the cloud (via the app to app picking feature, Flickr, SkyDrive, etc) as well as access to non file system data served up by media servers (DLNA) and WPD devices.

    also, WinRT includes image manipulation APIs that use the stream abstraction, see this sample:

    http://code.msdn.microsoft.com/windowsapps/Simple-Imaging-Sample-a2dec2b0

    Chris

    • Ditandai sebagai Jawaban oleh phil_ke 14 Maret 2012 7:54
    14 Maret 2012 5:14

Semua Balasan

  • Your app doesn't have access to that file and so cannot directly access it. You cannot get the broker's token (that would be an privilege escalation), but have to let the broker access the file on your behalf. It will then provide the file data in the StorageFile returned from the FilePicker and you can access that stream.

    --Rob

    13 Maret 2012 16:31
  • Thanks Rob!

    I understand that only the broker can give me a file but the 3rd party lib does not know anything about streams from winrt. 

    Let me give you a use-case of a photo app:

    1. User selects photos from from all over his computer via the file picker that he wants to have in her photo album

    2. A winrt component should generate blends between some of the photos or do some other kind of image manipulation

    3. The component uses a 3rd party imagemagick dll that can open files only via standard FILE I/O operations and via buffer operations on a void* buffer. 

    4. I was under the impression that once my app has access to a file via the users permission using a FilePicker/FolderPicker the same access rights to this file span from my metro app to all WinRT components running in the same process. 

    5. The only option left currently would be to use buffer functions of the 3rd party lib. But WinRT does not provide MemoryMapped files (which would be ideal for such kind) but instead I would have to allocate the memory beforehand and read in the whole file. That of course bloats the memory footprint of my app.

    What is the MS recommended way to handle such use cases? Should we copy all photos to our app local storage (where we have full File IO access to)? This would involve massive disk operations which drain the batteries of the device.

    Additionally I would like to ask: Why wasn't CreateFile hooked to transparently access files that the app already has permissions for? After all, the Metro runtime already knows which files the user picked and allowed the app access to. It could just inject this knowledge into a custom CreateFile overriden function and allow opening such files without problems (within the same process).

    13 Maret 2012 17:17
  • Hi Phil,

    Also consider that the StorageFile returned from the FilePicker may not be backed by the file system at all: the user may have selected a picture from another app using the App to App Picking contract.

    As you suggest, if the 3rd party DLL cannot take a stream then you would need to either save the stream to a file or convert it to a buffer. I'd lean towards the in memory buffer, but it depends on the specific needs of the app.

    CreateFile can't be readily hooked for this because the app technically doesn't have permissions to read the file. The "permission" is only at a high level and is handled by letting the broker (which does have permissions to read the file) read it and then hand it over the wall.

    You might also talk to the authors of the DLL to see if they can accept a stream. I suspect they'll need to update the DLL to pass certification for use in a Metro style app.

    --Rob

    • Ditandai sebagai Jawaban oleh phil_ke 14 Maret 2012 7:54
    13 Maret 2012 19:58
  • the library that you are using needs to be updated to use the WinRT stream abstraction, IRandomAccessStream.

    this enables access to "files" stored in the cloud (via the app to app picking feature, Flickr, SkyDrive, etc) as well as access to non file system data served up by media servers (DLNA) and WPD devices.

    also, WinRT includes image manipulation APIs that use the stream abstraction, see this sample:

    http://code.msdn.microsoft.com/windowsapps/Simple-Imaging-Sample-a2dec2b0

    Chris

    • Ditandai sebagai Jawaban oleh phil_ke 14 Maret 2012 7:54
    14 Maret 2012 5:14
  • Yes Chris, that's what I'd figured out already. I will implement IRandomAccessStream in the library today. The image manipulation was just an example, I would of course use the WinRT provided functionality for that :)
    14 Maret 2012 7:54