.NET file commands - suddenly starting 2 weeks ago .net File.Copy and File.Delete started locking fi-CodePudding

25 year old vb.net code. Same code hasn't changed for years. Suddenly starting at about 2-3 weeks ago any File.Copy() or File.Delete() - these are root .net functions- started locking files. Never releases lock. I have to go on fileshare look for open files and release lock. Every time. All my programs are crashing. Anyone else having problems with .net file commands? Crazy. This is happening on fileshare drives and administrative shares.

I re-wrote one function using cmd.exe running Robocopy instead of File.Copy and that worked. The problem is not permissions. Robocopy works. File.Copy does not. I ran this in debug mode and compiled. Both lock files. Everything was compiled on Microsoft Visual Studio Professional 2019

Here is an example that locks a file. It creates the file writes a line and closes the file then when it gets to x = 2 and tries to delete file- it throws an exception saying file is locked. I have to go in and close the open file on the fileserver. If I switch the location to a local drive location like c:\temp- this code works perfectly. No locks, no errors.

Imports System.IO
    Try
        Dim StrWriter As StreamWriter
        Dim x As Integer
        For x = 1 To 5
            If File.Exists("\\fs1\public1\LogFile.txt") Then
                File.Delete("\\fs1\public1\\LogFile.txt")
            End If
            StrWriter = File.CreateText("\\fs1\public1\\LogFile.txt")
            StrWriter.WriteLine("Hello")
            StrWriter.Close()
        Next


    Catch ex As Exception
        MsgBox(ex.Message)
    End Try

CodePudding user response：

The File.CreateText() documentation includes this info:

Creates or opens a file for writing UTF-8 encoded text. If the file already exists, its contents are overwritten.

Therefore the Exists() and Delete() code are not necessary at all. If the file already exists, we can call CreateText() with no other checks and any existing file is replaced (deleted) automatically. Everything can reduce to this:

Try
   Using writer As StreamWriter = File.CreateText(@"\\fs1\public1\LogFile.txt")
        writer.WriteLine("Hello")
   End Using
Catch ex As Exception
    MsgBox(ex.Message)
End Try

This will also likely (no guarantees) fix the issue in the question. The reason is the most likely source was an exception or other failure to reach or fully execute the StrWriter.Close() line, such that the stream was left open. The Using block makes stronger guarantees about disposing the stream. You should also track down other code which writes to this log file and update it to also use Using block.

It's also possible the issue is external to the code: whoever is responsible for monitoring this log file is using a new tool that locks the file while they have it open, and they are leaving this tool running in the background. Or maybe it's the same tool, but the behavior changed, where now they leave it running when before they would have closed it.

One other thing to mention is it's now better practice to use a fully-qualified name for the server. Instead of just fs1, use something like fs1.myADdomain.example. This helps speed name resolution, makes it less likely for authentication to fall back to older/weaker mechanisms, and is one part of allowing better-encrypted traffic between the client and server.

CodePudding user response：

In case anyone comes across this issue- it's not anything to do with programming. It is from anti-virus software. My AV software was randomly locking files on the fileshare that my program was copying or trying to delete.