Filestream.write（）的File.Delete问题

Question

I have refresh button. On refresh, I need to download a file and de-serialize its contents to read the information in it. Below is the method used to download the file.

public void DownloadVersionContents(long fileID,string fileName)
        {
            if (File.Exists(path))
              {
                 File.Delete(path);
              }
            Stream stream = service.DownloadContent(fileID);

            using (FileStream fileStream = File.OpenWrite(fileName))
            {
                // Write the stream to the file on disk.
                var buf = new byte[1024];
                int numBytes;
                while ((numBytes = stream.Read(buf, 0, buf.Length)) > 0)
                {
                    fileStream.Write(buf, 0, numBytes);
                }
                fileStream.Close();
            }
            stream.Close();
        }

Everytime the refresh button is clicked, I have to delete the file and download latest file from the server. If the refresh is called with in a second or two im getting an error saying

System.IO.IOException was caught
  HResult=-2147024864
  Message=The process cannot access the file 'C:\Users\...\AppData\Local\Temp\mapping - copy.xml' because it is being used by another process.
  Source=mscorlib
  StackTrace:
       at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
       at System.IO.File.InternalDelete(String path, Boolean checkHost)
       at System.IO.File.Delete(String path)

If the refresh is called after at least 10 or 20 seconds,im not getting any error. The file is never opened nor used yet. Kindly help. Edit: Sorry I forgot to mention, Im de-serializing the file using this method immediately after refresh is called.

public static T DeSerializeFromFile<T>(string xmlFilePath) 
        {
            T instance = default(T);

            if (xmlFilePath != null)
            {
                var reader = new StreamReader(xmlFilePath);
                var serializer = new XmlSerializer(typeof(T));
                instance = (T)serializer.Deserialize(reader);
            }
            return instance;
        }

The refresh button is called again after the values are updated.

Answer 1

It sounds like the file takes longer than a couple seconds to get written. If the file is still being written to, then no, you certainly won't be able to delete it. You have a couple options.

The simplest, and probably best, is to keep track of whether you're still writing to it.

private bool IsWriting = false;
public void DownloadVersionContents(long fileID, string fileName)
{
    if (!IsWriting)
    {
        IsWriting = true;

        // Perform the delete and download

        IsWriting = false;
    }
}

Depending on the platform, you might want to reflect this in the UI as well, perhaps by disabling the "Refresh" button. This, of course, is assuming the file doesn't change more frequently than the time it takes to update. If it does, you may want to implement some cancellation pattern.

Beyond that, you could buffer the file directly into memory, then write it "all at once," which would probably only take a fraction of a second. Of course, if it's a big file, that won't be feasible.

Answer 2

This seems like a good time to use a try catch -block. Catch the exception and prompt the user if the file is busy.

try
{
    if (File.Exists(path))
         File.Delete(path);

    using(Stream stream = service.DownloadContent(fileID))
    {
        using (FileStream fileStream = File.OpenWrite(fileName))
        {
            // Write the stream to the file on disk.
            var buf = new byte[1024];
            int numBytes;
            while ((numBytes = stream.Read(buf, 0, buf.Length)) > 0)
            {
                fileStream.Write(buf, 0, numBytes);
            }
        }
    }
}
catch (IOException e)
{
    MessageBox.Show("The refresh failed, try again in a few seconds."); 
}

This wont speed up the refresh process but it will prevent the user from crashing your program by spamming refresh. Try to always have this kind of exception handling present when working with outside sources.