Bug 43062 - File.Replace() is not atomic when backup parameter is supplied
Summary: File.Replace() is not atomic when backup parameter is supplied
Status: CONFIRMED
Alias: None
Product: Runtime
Classification: Mono
Component: io-layer (show other bugs)
Version: master
Hardware: All All
: Normal normal
Target Milestone: Future Cycle (TBD)
Assignee: Bugzilla
URL:
Depends on:
Blocks:
 
Reported: 2016-08-04 17:31 UTC by Nathan Phillip Brink (binki)
Modified: 2016-08-29 08:20 UTC (History)
3 users (show)

Tags:
Is this bug a regression?: ---
Last known good build:

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.


Please create a new report for Bug 43062 on GitHub or Developer Community if you have new information to add and do not yet see a matching new report.

If the latest results still closely match this report, you can use the original description:

  • Export the original title and description: GitHub Markdown or Developer Community HTML
  • Copy the title and description into the new report. Adjust them to be up-to-date if needed.
  • Add your new information.

In special cases on GitHub you might also want the comments: GitHub Markdown with public comments

Related Links:
Status:
CONFIRMED

Description Nathan Phillip Brink (binki) 2016-08-04 17:31:46 UTC
This program:

    using System.IO;
    
    class Program
    {
        static int Main(string[] args)
        {
            File.Replace(args[0], args[1], args.Length > 2 ? args[2] : null);
            return 0;
        }
    }

yields this snippet of strace output:

    ohnobinki@gibby ~/mono-file-replace-atomicity $ touch a b c
    ohnobinki@gibby ~/mono-file-replace-atomicity $ strace mono program.exe a b c
    …
    open("/home/ohnobinki/mono-file-replace-atomicity/c", O_RDONLY) = 3
    rename("/home/ohnobinki/mono-file-replace-atomicity/b", "/home/ohnobinki/mono-file-replace-atomicity/c") = 0
    rename("/home/ohnobinki/mono-file-replace-atomicity/a", "/home/ohnobinki/mono-file-replace-atomicity/b") = 0

There is a time when the program or host computer could crash after b has been renamed to c and before a has been renamed to b. Instead of renaming b to c, hardlinks should be used so that no crash can cause b to cease to exist.

I was expecting this strace output (though instead of unlink() you could still open() the backup and try to restore it if possible if the other steps fail, just left out for simplicity in this case.):

    ohnobinki@gibby ~/mono-file-replace-atomicity $ touch a b c
    ohnobinki@gibby ~/mono-file-replace-atomicity $ strace ./realReplace $(realpath a) $(realpath b) $(realpath c)
    …
    unlink("/home/ohnobinki/mono-file-replace-atomicity/c") = 0
    link("/home/ohnobinki/mono-file-replace-atomicity/b", "/home/ohnobinki/mono-file-replace-atomicity/c") = 0
    rename("/home/ohnobinki/mono-file-replace-atomicity/a", "/home/ohnobinki/mono-file-replace-atomicity/b") = 0

My sample implementation can be seen at https://gist.github.com/binki/e40182e4098d9714a609918908c623b8 .

File.Replace() is assumed by .net programmers to be atomic. It is a wrapper around ReplaceFile() and https://msdn.microsoft.com/en-us/library/windows/desktop/hh802690%28v=vs.85%29.aspx#applications_updating_a_single_file_with_document-like_data declares that ReplaceFile() enables the programmer to write code that ensure that “the changes either are completely applied or not applied at all” regarding the state of the destination file. On POSIX this would be equivalent to taking advantage of how rename() enables replacement of the target file without unlinking the target file first. So mono’s File.Replace() should strive to implement at least that part of File.Replace() transactionally rather than unsafely like it does now.