This permission controls the ability to access files and folders. The permission distinguishes between the following three different types of file I/O access. (Full spec is here.)
All of these permissions are independent, meaning that rights to one don't imply rights to another. If more than one permission is desired, they can be or'd together as shown in the code sample at the end of this document. For instance, write permission does not imply read and append. File permission is defined in terms of canonical absolute path names; checks should always be made with canonical file path names.
The FileIOPermission describes protected operations on files and folders. A File class is implemented that provides secure access to files and folders. The security access check is done at the time the handle to the file is created. By doing the check at creation time, the cost of the security check is minimized. Opening a file happens once, while reading and writing happen multiple times. Once the file is opened no further checks are done. If the object is passed to an untrusted caller, then it can be misused. File permission access is only checked on the file open. This means for example that file handles should not be stored in global statics where code with less permission might get at them.
The parameter strings in the permission methods can be either case sensitive or case insensitive. This setting, which will be controlled by a flag in the admin tool, will allow for the model to extend to other platforms beyond Windows. The flag will set the case sensitivity for both the permissions and the file objects themselves so that their case sensitivity is consistent.
The flags specify the actions that can be performed on the file(s) or folder(s): Read, Write, and Append. In addition, the actions can be or'ed together to form more complicated access requests. See code sample at end of document for examples.
Folder access implies access to all files it contains and below it in sub-/subsub-/etc.-folders.