CoreWebView2Environment.CreateWebFileSystemDirectoryHandle Method
Definition
Important
Some information relates to prerelease product that may be substantially modified before it’s released. Microsoft makes no warranties, express or implied, with respect to the information provided here.
Creates a CoreWebView2FileSystemHandle object from a path that represents a Web FileSystemDirectoryHandle.
public Microsoft.Web.WebView2.Core.CoreWebView2FileSystemHandle CreateWebFileSystemDirectoryHandle (string Path, Microsoft.Web.WebView2.Core.CoreWebView2FileSystemHandlePermission Permission);member this.CreateWebFileSystemDirectoryHandle : string * Microsoft.Web.WebView2.Core.CoreWebView2FileSystemHandlePermission -> Microsoft.Web.WebView2.Core.CoreWebView2FileSystemHandlePublic Function CreateWebFileSystemDirectoryHandle (Path As String, Permission As CoreWebView2FileSystemHandlePermission) As CoreWebView2FileSystemHandleParameters
- Path
- String
The path pointed by the directory.
This must be a syntactically correct fully qualified path, but it is not checked here whether it currently points to a directory. Any other state validation will be done when this handle is accessed from web content and will cause DOM exceptions if access operations fail. If an invalid path is passed, an InvalidArgumentException will be thrown.
- Permission
- CoreWebView2FileSystemHandlePermission
This is used to specify whether the Handle should be created with a Read-only or Read-and-write web permission.
For the permission value specified here, the Web PermissionStatus will be [granted](https://developer.mozilla.org/docs/Web/API/PermissionStatus/state) and the unspecified permission will be [prompt](https://developer.mozilla.org/docs/Web/API/PermissionStatus/state). Therefore, the web content then does not need to call requestPermission for the permission that was specified before attempting the permitted operation, but if it does, the promise will immediately be resolved with 'granted' PermissionStatus without firing the WebView2 PermissionRequested event or prompting the user for permission. Otherwise, requestPermission will behave as the status of permission is currently Prompt, which means the PermissionRequested event will fire or the user will be prompted.
Note: An exception to this is, if there is a parent directory handle that has broader permissions in the same page context than specified in here, the handle will automatically inherit the most permissive permission of the parent handle when posted to that page context. i.e. If there is already a FileSystemDirectoryHandle to C:\foo that has write permission on a page, even though a CoreWebView2FileSystemHandle to directory C:\example\directory may be created with ReadOnly permission, when posted to that page, write permission will be automatically granted to the created handle.
Additionally, the app must have the same OS permissions that have propagated to the WebView2 browser process for the path it wishes to give the web content to make any operations on the directory. Specifically, the WebView2 browser process will run in same user, package identity, and app container of the app, but other means such as security context impersonations do not get propagated, so such permissions that the app has, will not be effective in WebView2.
Returns
Remarks
An app needs to be mindful that this object, when posted to the web content, provides it with unusual access to OS file system via the Web FileSystem API! The app should therefore only post objects for paths that it wants to allow access to the web content and it is not recommended that the web content "asks" for this path. The app should also check the source property of the target to ensure that it is sending to the web content of intended origin. Once the object is passed to web content, the path must point to a directory as if it was chosen via directory picker otherwise any IO operation done on the FileSystemDirectoryHandle will throw a DOM exception.