Hi How do I delete a local file in my application after copying it to the IsolatedStorage?
I want to delete only the file in local folder. Not in the Isolated Storage. I'm using WP 7.1.
tnks
You don't have write access to the folder where your application is installed. It's therefore impossible to delete the file.
Windows Phone is designed to be one of the most secure environments in the mobile market. If you look at many of the standards it enforces you will see that this is a consistent theme.
For example:
Your app does not have the ability to intercept calls or text
messages (though the library exists)
Your app cannot modify hardware buttons (there is a few MINOR
exceptions to this rule like manipulating the back button event)
Your app cannot access memory locations outside of the Isolated
Storage it is assigned by the phone.
These standards are put in place to protect the user from malicious software and to keep a clean and consistent feel across the environment.
Related
I'm converting a suite of legacy 32 bit C++ apps to run under Windows 10. These apps can run under different user accounts on the same PC and need to share the data between themselves and all the users. Some of the apps are Windows services, some are regular UI apps. There's a lot of communication between the apps and sometimes this is accomplished using shared data files. All the different user accounts need to access the shared data...
I have tried storing the shared data in C:\Program Files (x86)\Common Files\AppName\data
and have set the security level on that folder to Full Control for All users.
Most of the time, this works perfectly well. But occasionally, at seemingly random intervals, one of the shared data files ends up in:
C:\Users\UserName\AppData\Local\VirtualStore\Program Files (x86)\Common Files\AppName\data
I have tried to replicate this, and it never happens when I'm looking...
If I run a simple UI app that just writes to this folder, everything is fine. The App does not need to run with elevated privileges to write to the folder.
I suspect it's when one of the Apps is trying to write to a file that is locked by another, which the code handles by using exceptions, but Windows tries to help out by writing to the VirtualStore instead. But I could be wrong...
So, to cut to the question:
Where is the 'best place' to store shared data between several apps AND user accounts, that won't end up in the VirtualStore?
Andy
Any application with a requestedExecutionLevel node in its manifest is marked as Vista compatible and the redirection to the Virtual Store is disabled.
I came across the term "IsolatedStorage" in windows phone. Can anybody explain it in detail how is it related to windows phone applications? Also how does it affect while application version upgrade?
Isolated Storage refers the private read / write directories that each app has for storing their own data. It is isolated from all other apps on the system. When an app is upgraded via the store on an end-user's machine, the isolated storage is preserved.
Note that during development, Isolated Storage of an app can be deleted if you do a full rebuild of the project.
IsolatedStorage is a way of allowing apps to save files locally to the application within a device. Until the app is uninstalled, the IsolatedStorage for the application is persisted. If the user upgrades the app in the store, as long as there isn't a change in the way the IsolatedStorage is implemented, it will also be preserved during the update.
I am curious about this when I am getting to know more about programming WinRT app. Normally for regular Windows programs, developers can use system headers like WinINet.h or WinHttp.h, etc. However, it is not allowed to use them in an WinRT store app.
I was wondering what way they use to prevent developer from using those dlls, how do they check, and why they do this to developers?
Thank you
All Windows Store apps run inside of an AppContainer. All of the dlls and libraries that they are allowed to import/use are limited by the rights of the AppContainer. Generally, the apps have the rights of the user "ALL_APPLICATION_PACKAGES" I believe, so that means that they have the read/write capabilities of that user. They still are only able to access the system via the AppContainer, so any limitations imposed by the AppContainer still exist.
Now, there is a way around this. The developer can use the FileOpenPicker to allow the user to choose a file or folder (via the FolderPicker) that the program can use.
They do this to developers to make it so that the AppContainer is a very closed-off sandbox running in basically a virtual environment. In this way, simply for the fact that a program is running inside of the AppContainer, it can be said to protect the users data and prevent the installation of malware.
This does not necessarily prevent an app from social engineering or phishing. That is policed via the certification and compliance system.
Protecting user files with File History talks about File History, which is basically a continuous backup for Windows 8. The blog discusses File History in depth, and also discusses how to integrate SkyDrive.
I want to programmatically disable backup of certain files. The files live on another server, and there's no need to back them up locally or put them on someone else's cloud. The blog and related articles doe not talk about opt'ing out of the service for application data.
How does one programmatically: (1) disable local file backups; and (2) disable cloud based backups. I'm interested in settings for both Windows 8 (desktop or laptop) and Windows Phone 8.
Related: Both Android and Apple have similar. For Android, we add android:allowBackup and set it to false in AndroidManifest.xml. For Apple, we can use kCFURLIsExcludedFromBackupKey file property or com.apple.MobileBackup extended attribute.
Jeff
In Windows Phone 8, backup and restore settings are controlled by the user through system settings. An app cannot prevent itself from being backed up. However, note that the backup does not store any data associated with third party apps but rather only stores a list of installed apps
So basically you don't need to do anything in your app to prevent local files from being stored on SkyDrive if the user has enabled backup.
In Windows 8 everything can be backed up since an admin user will have full access to his computer files, I don't think you can restrict this. If you have sensitive data you can use DataProtectionProvider to protect it.
Many questions on SO say "Windows developer guidelines" or "windows design guidelines" say that you shouldn't write temporary or program data to the Program Files area, but as far as I can tell none of them actually link to a piece of documentation that says as much. Searching the MSDN has yielded me no results. Windows will make the area read-only, so it can be enforced by the OS, but that doesn't mean developers didn't try to write there anyway (e.g., when porting older, XP and earlier based programs forward.)
I realize that it seems odd to ask about it this late into Windows development (since, as a commenter below pointed out, has been enforced by the OS for more than a decade), but a document that says so is sometimes necessary to satisfy people.
With that in mind, Does Microsoft have a document published stating we shouldn't write application data to the Program Files area, and if so, where is it?
From Technical requirements for the Windows 7 Client Software Logo Program:
Install to the correct folders by default
Users should have a consistent and secure experience with the default
installation location of files, while maintaining the option to
install an application to the location they choose. It is also
necessary to store application data in the correct location to allow
several people to use the same computer without corrupting or
overwriting each other's data and settings.
Windows provides specific locations in the file system to store
programs and software components, shared application data, and
application data specific to a user:
Applications should be installed to the Program Files folder by default. User data or application data must never be stored in this
location because of the security permissions configured for this
folder (emphasis added)
All application data that must be shared among users on the computer should be stored within ProgramData
All application data exclusive to a specific user and not to be shared with other users of the computer must be stored in
Users\<username>\AppData
Never write directly to the "Windows" directory and or subdirectories. Use the correct methods for installing files, such as
fonts or drivers
In “per-machine” installations, user data must be written at first run and not during the installation. This is because there is no
correct user location to store data at time of installation. Attempts
by an application to modify default association behaviors at a machine
level after installation will be unsuccessful. Instead, defaults must
be claimed on a per-user level, which prevents multiple users from
overwriting each other's defaults.
And I'm quite sure that there's similar stuff for every Windows version of the NT family going back to Windows NT 4 or even earlier.
See also this question.
Edit: the original link in this post to the Windows 7 Logo program exists no more. Here you find the current link to the Certification requirements for Windows Desktop Apps. See Section 10, Apps must install to the correct folders by default
In later versions of windows (Vista, 7 and of course server versions) access permission are restricted for "special folders" including "Program Files". Even if your program is elevated to have sufficient privileges to write to this folder it is still a bad idea.
I don't know of any guidelines that state this but there is a list of special folders and what they are meant for. The fact that there is a special folder for nearly all types of data I can image means there is no need to use the program files folder.