I want to Read textFile in my Userfolder in UWP but i got error like this
'Access to the path 'C:\Users\Administrator\log\config.txt' is denied.'
string path = #"C:\Users\Administrator\log\config.txt";
string textValue = System.IO.File.ReadAllText(path);
Debug.WriteLine(textValue);
UWP can't read folder in a specific path???
UWP was designed as a sandbox to increase a user security. Thus, by default your app can see only limited list of folders, like its private subfolder or any of standard locations like My Docs, My Pictures etc. If you need something outside the default, there is a manifest permission to be specified (broadFileSystemAccess) or then let the user pick deisred file interactively to get explicit consent:
https://learn.microsoft.com/en-us/windows/uwp/packaging/app-capability-declarations
In most cases, to get access to file system locations, your app can
use the FileOpenPicker, FileSavePicker, FolderPicker, and
FutureAccessList APIs. If you want to request approval to use the
broadFileSystemAccess capability, then you must provide specific
reasons as to why those APIs aren't sufficient for your needs.
Related
I have a UWP project, and wrote this code:
foreach (var foldertype in (Environment.SpecialFolder[])Enum.GetValues(typeof(Environment.SpecialFolder)))
{
//string d = Environment.CurrentDirectory;
var path = Environment.GetFolderPath(foldertype);
var folder = await StorageFolder.GetFolderFromPathAsync(path);
StorageApplicationPermissions.FutureAccessList.Add(folder, folder.Path);
Debug.WriteLine($"Opened the folder: {folder.DisplayName}");
this.MenuFolderItems.Add(new MenuFolderItem(folder));
}
It is supposed to enumerate all the special folders, and get their folder. However, while debugging, this is what happens:
foldertype = Desktop
path = "C:\\Users\\cuent\\AppData\\Local\\Packages\\402b6149-1adf-4994-abc9-504111b3b972_a5s740xv383r0\\LocalState\\Desktop"
folder = [ERROR] System.IO.FileNotFoundException: 'The system cannot find the file specified. (Exception from HRESULT: 0x80070002)'
I do not know what is happening here, it seems to be appending the path to the installed location of the app. How do I fix this?
Expected output of GetFolderPath() is wherever the Desktop is, not the weird path.
UWP apps are different from desktop applications when accessing the file system. UWP apps are running in the sandbox so there are limitations for UWP apps when trying to access the file system. You could check this document: File access permissions. The document lists all the locations that UWP apps have permission to access.
Back to your scenario, what you need first is a broadFileSystemAccess restricted capability. This capability enables your app could use the StorageFolder.GetFolderFromPathAsync() API with a Path parameter. This is mentioned in the last part of the document I posted above.
Then the second issue is the Environment.GetFolderPath API. It looks like the API will return a Path that points to a local folder inside the app's local folder. But there is no such desktop folder inside the app's local folder so you will get the FileNotFoundException. You might need to set the correct path by yourself like C:\Users\your user name\Desktop. After that, your code should be able to work correctly.
I use the types StorageFile, StorageFolder and they need access to the file system, since the file is not opened by the user:
StorageFile storageFile = await StorageFile.GetFileFromPathAsync(filePath);
I need so that I can give the user permission to access the file system to my application:
How can I do it?
Your screenshot is app's access permission setting page, after add broadFileSystemAccess capability, your app will display in the list, you also need to manually enable broad file system in File System setting page. For getting the setting page, you could search file system keywords in setting app home page.
If you want to quickly access this page, you could use the following method. For more info please refer Launch the Windows Settings app.
bool result = await Windows.System.Launcher.LaunchUriAsync(new Uri("ms-settings:privacy-broadfilesystemaccess"));
For more info please refer uwp File access permissions.
The lyrics are nested in the music file, not downloaded from the internet. the MusicProperties does not have such attribute.
I have tried using Id3 package to read it and that requires path to the file. However, in UWP there seems no way to access a file using path like C:/Users/Seaky/Desktop/Music/SomeMusic.mp3 (at least not working for me as I get permission denied even with broadFileSystemAccess.).
What else can I try?
I have found a way to do that as Mp3 accepts a Stream object in its constructor. Therefore, I am able to do this:
public async Task<string> GetLyrics()
{
var file = await StorageFile.GetFileFromPathAsync(Path);
using (var stream = await file.OpenAsync(FileAccessMode.Read))
{
using (var mp3 = new Mp3(stream.AsStream()))
{
var lyrics = mp3.GetTag(Id3TagFamily.Version2X).Lyrics;
return lyrics.Count > 0 ? lyrics[0].Lyrics : "";
}
}
}
Accessing files from a UWP application outside a select number folders requires additional permissions.
As you've pointed out, you've added the broadFileSystemAccess capability to your app manifest, which should allow access to any file that the end-user has access to.
The broadFileSystemAccess capability still requires the end-user to authorize the application. The end-user is usually prompted to do this if broadFileSystemAccess capability is specified and the permission has not yet been granted, however, in some cases, this is broken. So you could check that the application has the required permissions, via the "Advanced Settings" link to your app under the Windows "Apps & settings" settings page.
If you're hardcoding the path, you could try letting the end-user pick the file using FileOpenPicker instead, to see if that makes a difference.
There is further information on file access permissions here.
The following code is taken from Microsoft's documentation on the subject with slight modification:
var folderPicker = new Windows.Storage.Pickers.FolderPicker();
folderPicker.SuggestedStartLocation = Windows.Storage.Pickers.PickerLocationId.Desktop;
folderPicker.FileTypeFilter.Add("*");
Windows.Storage.StorageFolder folder = await folderPicker.PickSingleFolderAsync();
if (folder != null)
{
// Application now has read/write access to all contents in the picked folder
// (including other sub-folder contents)
Windows.Storage.AccessCache.StorageApplicationPermissions.
FutureAccessList.AddOrReplace("PickedFolderToken", folder);
if (Directory.Exists(folder.Path)) // fails, I don't have permission to read this folder even though the documentation suggests that I should have access
{
this.textBlock.Text = "Picked folder: " + folder.Name; // never gets printed
}
}
I also tried adding the broadFileSystemAccess capability to the application manifest. What am I missing here?
broadFileSystemAccess only works with Windows.Storage namespace, and this is already mentioned in the docs as follows :
This is a restricted capability. On first use, the system will prompt
the user to allow access. Access is configurable in Settings > Privacy
File system. If you submit an app to the Store that declares this capability, you will need to supply additional descriptions of why
your app needs this capability, and how it intends to use it. This
capability works for APIs in the Windows.Storage namespace
UWP applications have limited access and the regular IO commands do not work, including System.Diagnostic.Process. The only way to launch a process is to use FullTrustProcessLauncher Class as documented here: https://learn.microsoft.com/en-us/uwp/api/Windows.ApplicationModel.FullTrustProcessLauncher.
Working examples can be found here: https://github.com/StefanWickDev/UWP-FullTrust
However, this does not solve the problem of working with existing libraries since they are not processes in the first place. We now have an RPC service where the requests are made from the service and results obtained.
I´m developing an app that is reading jpeg and pdf files from a configurable location on the filesystem.
Currently there is a running version implemented in WPF and now I´m trying to move to the new Windows Universal apps.
The following code works fine with WPF:
public IList<string> GetFilesByNumber(string path, string number)
{
if (string.IsNullOrWhiteSpace(path))
throw new ArgumentNullException(nameof(path));
if (string.IsNullOrWhiteSpace(number))
throw new ArgumentNullException(nameof(number));
if (!Directory.Exists(path))
throw new DirectoryNotFoundException(path);
var files = Directory.GetFiles(path, "*" + number + "*",
SearchOption.AllDirectories);
if (files == null || files.Length == 0)
return null;
return files;
}
With using Universal Apps I ran into some problems:
Directory.Exists is not available
How can I read from directories outside of my app storage?
To read from an other directory outside the app storage I tried the following:
StorageFolder folder = StorageFolder.GetFolderFromPathAsync("D:\\texts\\");
var fileTypeFilter = new string[] { ".pdf", ".jpg" };
QueryOptions queryOptions = new QueryOptions(CommonFileQuery.OrderBySearchRank, fileTypeFilter);
queryOptions.UserSearchFilter = "142";
StorageFileQueryResult queryResult = folder.CreateFileQueryWithOptions(queryOptions);
IReadOnlyList<StorageFile> files = queryResult.GetFilesAsync().GetResults();
The thing is: It isn´t working, but I get an exception:
An exception of type 'System.UnauthorizedAccessException' occurred in TextManager.Universal.DataAccess.dll but was not handled in user code
Additional information: Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED))
I know that you have to configure some permissions in the manifest, but I can´t find one suitable for filesystem IO operations...
Did someone also have such problems/a possible solution?
Solution:
From the solutions that #Rico Suter gave me, I chosed the FutureAccessList in combination with the FolderPicker. It is also possible to access the entry with the Token after the program was restarted.
I can also recommend you the UX Guidlines and this Github sample.
Thank you very much!
In UWP apps, you can only access the following files and folders:
Directories which are declared in the manifest file (e.g. Documents, Pictures, Videos folder)
Directories and files which the user manually selected with the FileOpenPicker or FolderPicker
Files from the FutureAccessList or MostRecentlyUsedList
Files which are opened with a file extension association or via sharing
If you need access to all files in D:\, the user must manually pick the D:\ drive using the FolderPicker, then you have access to everything in this drive...
UPDATE:
Windows 10 build 17134 (2018 April Update, version 1803) added additional file system access capabilities for UWP apps:
Any UWP app (either a regular windowed app or a console app) that declares an AppExecutionAlias is now granted implicit access to the files and folders in the current working directory and downward, when it’s activated from a command line. The current working directory is from whatever file-system location the user chooses to execute your AppExecutionAlias.
The new broadFileSystemAccess capability grants apps the same access to the file system as the user who is currently running the app without file-picker style prompts. This access can be set in the manifest in the following manner:
xmlns:rescap="http://schemas.microsoft.com/appx/manifest/foundation/windows10/restrictedcapabilities"
...
IgnorableNamespaces="uap mp uap5 rescap">
...
<Capabilities>
<rescap:Capability Name="broadFileSystemAccess" />
</Capabilities>
These changes and their intention are discussed at length in the MSDN Magazine article titled Universal Windows Platform - Closing UWP-Win32 Gaps. The articles notes the following:
If you declare any restricted capability, this triggers additional
scrutiny at the time you submit your package to the Store for
publication. ... You don’t need an AppExecutionAlias if you have this
capability. Because this is such a powerful feature, Microsoft will
grant the capability only if the app developer provides compelling
reasons for the request, a description of how this will be used, and
an explanation of how this benefits the user.
further:
If you declare the broadFileSystemAccess capability, you don’t need to
declare any of the more narrowly scoped file-system capabilities
(Documents, Pictures or Videos); indeed, an app must not declare both
broadFileSystemAccess and any of the other three file-system
capabilities.
finally:
Even after the app has been granted the capability, there’s also a
runtime check, because this constitutes a privacy concern for the
user. Just like other privacy issues, the app will trigger a
user-consent prompt on first use. If the user chooses to deny
permission, the app must be resilient to this.
The accepted answer is no longer complete. It is now possible to declare broadFileSystemAccess in the app manifest to arbitrarily read the file system.
The File Access Permissions page has details.
Note that the user can still revoke this permission via the settings app.
You can do it from UI in VS 2017.
Click on manifest file -> Capabilities -> Check photo library or whatever stuff you want.
According to MSDN doc : "The file picker allows an app to access files and folders, to attach files and folders, to open a file, and to save a file."
https://msdn.microsoft.com/en-us/library/windows/apps/hh465182.aspx
You can read a file using the filepicker through a standard user interface.
Regards
this is not true:
Files which are opened with a file extension association or via sharing
try it, by opening files from mail (outlook) or from the desktop...
it simply does not work
you first have to grant the rights by the file picker.
so this ist sh...
This is a restricted capability. Access is configurable in Settings > Privacy > File system. and enable acces for your app. Because users can grant or deny the permission any time in Settings, you should ensure that your app is resilient to those changes. If you find that your app does not have access, you may choose to prompt the user to change the setting by providing a link to the Windows 10 file system access and privacy article. Note that the user must close the app, toggle the setting, and restart the app. If they toggle the setting while the app is running, the platform will suspend your app so that you can save the state, then forcibly terminate the app in order to apply the new setting. In the April 2018 update, the default for the permission is On. In the October 2018 update, the default is Off.
More info