none
C#/.NET equivalent for _access: Is non ReadOnly files read/write? RRS feed

  • Question

  • Good day, I have been trying to find an equivalent method or API for C/C++'s io.access (https://msdn.microsoft.com/en-us/library/1w06ktdy.aspx)

    based on it's description, I have found that it is similar with FileInfo.IsReadOnly (https://msdn.microsoft.com/en-us/library/system.componentmodel.readonlyattribute(v=vs.110).aspx)

    C/C++ io.access: "Determines if a file is read-only or not"

    C# FileInfo.IsReadOnly: "Gets or sets a value that determines if the current file is read only."

    From the description, I assumed that NOT readonly files is read/write, and used this to implement io.access' mode for 02: write-only AND 06: read and write.

    C/C++ io.access:

    Mode Value checks file for

    00 - Existence only

    02 - Write-Only

    04 - Read-Only

    06 - Read-and-write

    Implementation for FileInfo.IsReadOnly:

    FileInfo.IsReadOnly bool return

    false - Write-Only

    true - Read-Only

    false - Read-and-Write

    *note: File.Exists is implemented for mode 0: File existence

    I have already confirmed that io.access and implementation of FileInfo.IsReadOnly behaves the same with ReadOnly files and NOT ReadOnly files.

    I just need to see if there are any supporting documents claiming that Non ReadOnly Files = Read/Write.

    Please Help, Thanks!

    Thursday, December 21, 2017 8:43 AM

All replies

  • All methods call in the end GetFileAttributesEx() (which calls NtQueryFullAttributesFile())

    which returns File Attribute Constants


    Thursday, December 21, 2017 10:08 AM
  • The Windows impl of _access/_waccess uses the file attribute ReadOnly so checking for 4 and 6 are equivalent to checking for the ReadOnly attribute. As discussed in the documentation, Windows doesn't look at the ACLs so the other modes are not really useful in Windows. 

    "I just need to see if there are any supporting documents claiming that Non ReadOnly Files = Read/Write."

    That doesn't really make sense to me. ReadOnly indicates Not Read/Write. So Not ReadOnly would be Not Not Read/Write which is Read/Write. Not really sure why you need documentation to validate a double negative or to clarify that the only 2 options (in this particular case) are Read and Write. Note that Not ReadOnly may indicate RW but it doesn't necessarily mean Create and Delete. Those aren't represented by attributes (or handled by the _access function).


    Michael Taylor http://www.michaeltaylorp3.net

    Thursday, December 21, 2017 3:46 PM
    Moderator
  • Thanks for the reply,

    given that in C#/.NET FileInfo.IsReadOnly, there are only TWO types of files: readonly and NOT readonly.

    BUT in C/C++ io.access there are THREE types of files: write-only(not sure what this means in C#/.NET), read-only, and read/write.

    If I could prove that in C#/.NET imp there are really ONLY two types of files, and that .IsReadOnly = false = read/write.(It would also help to have some clarity on the write-only file)

    given the distinction between io.access mode 2:write-only and 4:read/write, I could prove that write-only = IsReadOnly = false, and read/write is also = IsReadOnly = false.

    Thursday, December 21, 2017 11:52 PM
  • As I said, _access() calls GetFileAttributesEx()

    and just tests FILE_ATTRIBUTE_READONLY and FILE_ATTRIBUTE_DIRECTORY

    (see the source code in access.cpp and waccess.cpp...)

    Friday, December 22, 2017 12:42 AM
  • "BUT in C/C++ io.access there are THREE types of files: write-only(not sure what this means in C#/.NET), read-only, and read/write."

    You're talking about a low level function in C that was designed to be OS agnostic back when POSIX was the common target. Write doesn't mean anything outside a unix-like environment. In the Unix world this function is supposed to look at the user permissions on the object to identify the rights. In Windows, as documented in MSDN, it only looks at the file attributes and therefore only read-only is supported. The other modes don't make sense for Windows. There is no real equivalent function for Windows. In the C function (based upon the documentation) it relies on the user's permissions (but not effective permissions). Windows is far more complicated in this regard. The closest equivalent would be to get the File/DirectorySecurity of the file/directory and then look at the rights. But this is far more complicated than just using the attribute.

    Is there some requirement that you have around implementing the C function _access in C#? If so then I'd say either use the file attributes (which are insufficient) or go with the actual ACL security (which is far more accurate but slower).


    Michael Taylor http://www.michaeltaylorp3.net

    Friday, December 22, 2017 1:07 AM
    Moderator
  • "Is there some requirement that you have around implementing the C function _access in C#?"

    yes, the whole objective of my project is to port legacy C/C++(which uses io.access and all its modes) to C#/.Net. 

    In this case, would implementation of FileIOPermissionAccess be more appropriate?

    (https://msdn.microsoft.com/en-us/library/system.security.permissions.fileiopermission.getpathlist(v=vs.110).aspx)

    Friday, December 22, 2017 1:53 AM
  • No, FileIOPermissionAccess is not the correct solution. CAS is effectively dead and policy-driven anyway. This has little to do with _access.

    Unfortunately directly mapping function A to function B will only get you so far. You'll need to look at each place you are using _access and determine if it really just cares about whether a file is read only or not. If so then the file attribute will be fine. However if the check is for something else or for a directory then you'll need to look at the security instead via GetAccessControl. But, depending upon case, it might simply be easier to try to read/write the file in question and capture the UnauthorizedAccessException instead.

    If you're migrating a large program I might also recommend that you consider using a helper tool to convert the base code so you can focus on the parts that require though. I have used Instant C++ to C# in the past against a 1000+ file code base and it got me about 70% there. Of course that code was littered with pointers and unions which makes migration much harder.


    Michael Taylor http://www.michaeltaylorp3.net

    Friday, December 22, 2017 2:03 AM
    Moderator