Windows 10 Universal App File/Directory Access - c#

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

Related

uwp How to read the files under the specified directory

(c# UWP) How to read files in any directory without using file selectors?
This is my code:
var t = Task.Run(() => File.ReadAllText(#"D:\chai.log"));
t.Wait();
Thrown exception:
Access to the path 'D:\chai.log' is denied.
Thanks!
Windows 10 Build 17093 introduced broadFileSystemAccess capability which allows apps to access folders which the current user has access to.
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
MSDN Documentation
broadFileSystemAccess
Windows.Storage
Access to user's files and folders are denied. In a UWP app, only the files or folders that are picked by the user can be accessed to read or write.
To show a dialog for the user to pick files or folders, write this code below:
var picker = new Windows.Storage.Pickers.FileOpenPicker();
picker.FileTypeFilter.Add(".log");
Windows.Storage.StorageFile file = await picker.PickSingleFileAsync();
if (file != null)
{
// Application now has read/write access to the picked file
}
Read Open files and folders with a picker - UWP app developer | Microsoft Docs for more details of the FileOpenPicker.
If you want future access to the files or folders the user picked this time, use MostRecentlyUsedList to track these files and folders.
Windows.Storage.StorageFile file = await picker.PickSingleFileAsync();
var mru = Windows.Storage.AccessCache.StorageApplicationPermissions.MostRecentlyUsedList;
string mruToken = mru.Add(file, "Some log file");
And you can enumerate your mru later to access the files or folders in the future:
foreach (Windows.Storage.AccessCache.AccessListEntry entry in mru.Entries)
{
string mruToken = entry.Token;
string mruMetadata = entry.Metadata;
Windows.Storage.IStorageItem item = await mru.GetItemAsync(mruToken);
// The type of item will tell you whether it's a file or a folder.
}
Read Track recently used files and folders - UWP app developer | Microsoft Docs for more details of the MostRecentlyUsedList.

C# UWP using System.IO.Directory return empty array?

i am trying to return all the files contain in a folder in UWP application for Windows 10, the code is shown below:
var path = #"C:\Users\Desktop";
var files = System.IO.Directory.GetFiles(path); //get empty arrays
But, i get empty string arrays, may I know what causes this problem?
You can't. For uwp and store apps, only the app installation and app temp folders are granted for direct access. 'Direct' means ... accesses without Windows.Storge broker process. (System.IO is 'direct'.)
If you want to access the 'outside' of your app - like as desktop, you need to ask user to pick the location by File/FolderPicker. Without the user interaction, you can't access.
However, Windows.Storage broker service provide the rich methods for file operation, and additional functions like as CommnonQuery features.
There are some exception for pictures, video folders, but the basic concept is same.
Following link may helps you. :)
File access permissions
Probably because C:\Users\Desktop doesn't exist on the system - it would be under C:\Users\YOUR_USERNAME\Desktop.
Additionally, your application might be operating in a sandbox, so all filesystem access will be virtualized to a private silo elsewhere - Windows would pretend that the directory you specified exists but says it's empty, because it doesn't want you accessing the user's files without prior permission.

Where can i place common user data other than LOCALMACHINE -Registry without Administrative Rights

In Windows other than the registry -localmachine where can I place common user data that could be accessed by all users.
i need to do this without requesting elevation of admin rights
You can store it in the Application data folder. which you can get from Envorinment:
var appDataFolder = Environment.GetFolderPath(Environment.SpecialFolder.CommonDocuments);
To determine if you can access the folder without admin right, run Visual Studio, without admin rights, and see if this code executes successfully.
class Program
{
static void Main(string[] args)
{
var folder = Environment.GetFolderPath(Environment.SpecialFolder.CommonDocuments);
var file = Path.Combine(folder, "testfile.txt");
File.WriteAllText(file, " Test Settings");
Console.ReadLine();
}
}
No such location is available by default. Regular (i.e., non-administrative users) do not have the requisite privileges to mess with system files or files that belong to other users—that would be a security issue. As such, they would not be able to write to a "common" directory.
If you need all users to be able to write to some type of common area, you need to set it up yourself. Generally, this is done by an installer application. The installer application will need to request elevation so that it has administrative privileges in order to write to restricted folders and alter security rights. If you're using a standard installer utility, then this is usually a built-in feature. If you're writing your own, you arrange for it to have administrative privileges by embedding a manifest with level set to requireElevation (search Stack Overflow for details).
The installer it will create a sub-directory of the common application data folder (the enumerated value Environment.SpecialFolder.CommonApplicationData in the .NET world) for your application's use. By default, of course, that sub-directory will inherit the restrictions of its parent folder, so the installer will also need to explicitly set the ACL (access control list) on that sub-directory to grant all users write access. This can be done in the .NET Framework using the Directory.SetAccessControl method.
Then, after installation is complete, administrative privileges will not be required to run your application. The application can just save into its own sub-directory of the common application data folder, which its installer has ensured that all users have read/write access to.

Open extern SQLite-Database in a Windows 8 Metro-App?

I use the "Sqlite for Windows Runtime" and sqlite-net (just as described at http://timheuer.com/blog/archive/2012/08/07/updated-how-to-using-sqlite-from-windows-store-apps.aspx) to develop a Windows 8 Metro-App, just . If I want to open a Database at the Program-Directory is no problem:
var dbPath = Path.Combine(Windows.Storage.ApplicationData.Current.LocalFolder.Path, "db.sqlite");
using (var db = new SQLite.SQLiteConnection(dbPath)) {
...
}
But when I want to use an extern Path like this:
var dbPath = "C:\\Users\\xxxxxx\\db.sqlite";
then an error occurs with "Cannot open database file". Why? Here I am using C#, normally I use C++, but for this problem I am sure it doesn't matter ;)
You cannot select arbitrary files on the file system. See here for details.
By default you can access these locations:
Application install directory
Application data locations
User’s Downloads folder
and
Additionally, your app can access some of the files on connected
devices by default. This is an option if your app uses the AutoPlay Device extension to launch automatically when users connect a device,
like a camera or USB thumb drive, to their system. The files your app
can access are limited to specific file types that are specified via
File Type Association declarations in your app manifest. Of course,
you can also gain access to files and folders on a removable device by
calling the file picker (using FileOpenPicker and FolderPicker) and
letting the user pick files and folders for your app to access. Learn
how to use the file picker in Quickstart: Accessing files with file pickers.
If you have the right capabilities declared you can also access:
Documents Library
Music Library
Picture Library
Videos Library
Homegroup Library
Removable devices
Media server devices (DLNA)
Universal Naming Convention (UNC) folders
A combination of the following capabilities is needed.
The home and work networks capability:
PrivateNetworkClientServer
And at least one internet and public networks capability:
InternetClient InternetClientServer
And, if applicable, the domain credentials capability:
EnterpriseAuthentication
Note You must add File Type Associations to your app manifest that declare specific file types that your app can access in this location.
In windows metro application...
It support only sandbox property of an application.
So you cant use
var dbPath = "C:\\Users\\xxxxxx\\db.sqlite";
U can only store data in local storage or application installed directory.
Please avoid to use any other path . it will not work .

Can't copy file with appropriate permissions using FileIOPermission

This snippet works well if I try to write in a user directory but as soon as I try to write in Program Files, it just executes silently and the file has not been copied (no exception). If I try to copy the file in C:\ or in C:\Windows I catch an UnauthorizedAccessException.
Do you know another way to get the permissions to write in that directory or to make it work another way?
Any help greatly appreciated! Thanks
using(FileStream fs=File.Open(source, FileMode.Open)){ }
try
{
FileIOPermission fp = new FileIOPermission(FileIOPermissionAccess.Write,
AccessControlActions.Change, "C:\\Program Files\\MyPath");
fp.Demand(); //<-- no exception but file is not copied
File.Copy("C:\\Users\\teebot\\Documents\\File.xml","C:\\Program Files\\MyPath\\File.xml",true);
}
catch(SecurityExceptions)
{
throw(s);
}
catch(UnauthorizedAccessException unauthroizedException)
{
throw unauthroizedException;
}
If you are running under Vista then the system just redirects writes to the program files folder, this is done so old program that keep their configuration in the program directory will continue to work when the user is not an Admin (or UAC is enabled).
All you have to do is add a manifest to your program that specify the required access level, then the system assume your program is Vista-aware and turns off all those compatibility patches.
You can see an example of a manifest file on my blog at:
http://www.nbdtech.com/blog/archive/2008/06/16/The-Application-Manifest-Needed-for-XP-and-Vista-Style-File.aspx
(the focus of the post is on getting the right version of the common controls, but the Vista security declarations are also there)
Don't write in the Program Files folder.
That's a big no-no, and will especially cause problems when the day comes where your code runs in Vista or on a machine at a company where users only get standard security rather than admin rights. Use the Application Data folder instead.
Are you running on Vista? If so then you may be running into file system virtualization. This is a feature in 32 bit versions of Vista which allows a normal user to write to protected parts of the file system. It's a shim introduced to reduce the pain of the LUA features of Vista.
The short version is that the operating system will create a virtual file system for certain protected roots (such as program files). When a non-admin attempts to write to it, a copy will be created an editted instead of the original. When your user account attempts to look at the file it will see the edit.s Other user accounts will only see the original.
Longer Version: http://thelazyadmin.com/blogs/thelazyadmin/archive/2007/04/26/file-system-virtualization.aspx
Code access security grants or denies permissions to your code.
It can't be used to override permissions that are granted/denied to the current user.

Categories

Resources