Menu

#7 File.Replace fails if both files are not on the volume

open-later
nobody
None
5
2009-12-22
2009-07-24
Anonymous
No

The File.Replace call in the FileMove Function in FileMover.cs is failing when the source and target files are not on the same volume.

I see someone covered this here:
http://thisoldcode.net/PermaLink,guid,fb85b396-97c8-43db-a9e8-5b153a3f81ff.aspx

I'm getting the exception noted there.
"System.IO.IOException: Unable to move the replacement file to the file to be replaced. The file to be replaced has retained its original name."

A possible fix is to catch the IOException and use the failback replace

catch (IOException)
{
// files are not on the same drive so the replace fails
NonNtfsReplace(sourceLocation,
targetLocation,
backupLocation);
}

Discussion

  • Andrew Pearmund

    Andrew Pearmund - 2009-12-21

    If this was only caused by the bug in the name of the .$$$ working file that caused it to be located in the current working directory not the audio source directory, then the problem will no longer arise as that bug has been fixed.
    If, on the other hand, the client code can nominate the output file to be on any drive, a more general file replace routine would come in useful.
    Votes either way?

     
  • Edward Brey

    Edward Brey - 2009-12-22

    IIRC from my use of the API, currently, the application cannot specify separate source and destination file names. If this is the case, then the fact that a copy is created and renames are used to replace the original is an implementation detail of the library. In theory, this could be changed in a future to use a more efficient method, e.g. the NTFS transactional file system introduced in Windows Vista: http://msdn.microsoft.com/en-us/magazine/cc163388.aspx

    If we are assuming that the library is only guaranteeing that the original file will be somehow updated, we can safely assume that the temporary file will be on the same volume as the destination file.

     
  • Andrew Pearmund

    Andrew Pearmund - 2009-12-22

    One day it would be nice to allow the temp or output files to be specified through the API, and then we will need to handle this better. For now, though, it's probably good enough as it is, unless someone wants to do something fancy with TxF.

     
  • Andrew Pearmund

    Andrew Pearmund - 2009-12-22
    • status: open --> open-later
     

Log in to post a comment.