rnkjnk
rnkjnk

Reputation: 45

Testing if I have full read/write access to a file in VB .NET 4.5 before processing it

I'm writing a windows service which runs as the local system account. I'm trying to make sure if I have full read/write access to a file beginning to process it any further. Here is my code:

    Dim FullPath As String
    FullPath = "C:\directory\file.txt"
    Dim ps As Security.PermissionSet
    ps = New Security.PermissionSet(Security.Permissions.PermissionState.Unrestricted)
    ps.AddPermission(New Security.Permissions.FileIOPermission(Security.Permissions.FileIOPermissionAccess.AllAccess, FullPath))
    ps.AddPermission(New Security.Permissions.FileIOPermission(Security.Permissions.FileIOPermissionAccess.AllAccess, IO.Path.GetDirectoryName(FullPath)))
    Try
        ps.Demand()
    Catch ex As Security.SecurityException
        System.Diagnostics.EventLog.WriteEntry("ShopLink", "File " + FullPath + " will not be parsed. " + ex.Message)
        Exit Sub
    Catch ex As Exception
        System.Diagnostics.EventLog.WriteEntry("ShopLink", "File " + FullPath + " will not be parsed. " + ex.Message)
        Exit Sub
    End Try

Then I set the full access permissions for the file to "Deny" for the user account my service is running as. After executing, the code above doesn't throw any exceptions and allows file processing to begin. When the service later tries to change and/or delete the file, I get an "Access Denied" exception.

Any suggestions?

Upvotes: 2

Views: 5418

Answers (3)

Karl Sangree
Karl Sangree

Reputation: 111

Using "Kill"... I know this is a very old thread but I'll add this in case anyone stumbles on it like I did. I was working on some old VB6 legacy code. One of my clients users was getting a runtime exception during a file open after a kill. The code was "Killing" the file and then rebuilding it from scratch with binary data held in memory. It tuns out that the "Kill" function triggered the user's anti-virus software which locked the file long enough to cause the next "Open" statement to fail. I discovered this using an error logging utility (the name escapes me at the moment). The line in the error log file on the failed "Open" statement was that the file's status was "Delete pending" due to the user's anti-virus software.

Upvotes: 0

rnkjnk
rnkjnk

Reputation: 45

I have solved the problem by using My.Computer.FileSystem.DeleteFile to delete the file instead of Kill. My.Computer.FileSystem.DeleteFile was executed without problems after successfully demanding full read/write access to the file in the way described above, while Kill consistently threw an "Access denied" exception.

Upvotes: 1

Basti
Basti

Reputation: 1004

For this purpose i use thise small function:

  Private Function HasAccess(ByVal ltFullPath As String)
    Try
      Using inputstreamreader As New StreamReader(ltFullPath)
        inputstreamreader.Close()
      End Using
      Using inputStream As FileStream = File.Open(ltFullPath, FileMode.Open, FileAccess.ReadWrite, FileShare.None)
        inputStream.Close()
        Return True
      End Using
    Catch ex As Exception
      Return False
    End Try
  End Function

In your case then:

If HasAccess(FullPath) ...

Upvotes: 2

Related Questions