Directory.Move behaves differently on Unix vs. Windows

[alexischr]

The following program throws System.IO.IOException: Cannot create a file when that file already exists on Windows, but succeeds (and silently replaces the destination file) on i.e. macOS:

using System;
using System.IO;

namespace MoveFile_DestFile_Exists
{
    class Program
    {
        static void Main(string[] args)
        {
            string TempFolder = Path.GetTempPath ();
            string tempFile1 = Path.Combine (TempFolder, "temp1.txt");
            string tempFile2 = Path.Combine (TempFolder, "temp2.txt");

            using (StreamWriter sw = File.CreateText (tempFile1)) {
                sw.Write ("temp1");
            }
            using (StreamWriter sw = File.CreateText (tempFile2)) {
                sw.Write ("temp2");
            }

            Directory.Move (tempFile1, tempFile2);
        }
    }
}

For context, expecting this to fail is part of Mono's tests.

[marek-safar]

@karelz @danmosemsft what is your take on this issue?

[jkotas]

cc @JeremyKuhne

[JeremyKuhne]

Seems like a bug/test hole to me. It should fail like Windows does if the destination exists when moving a file via Directory.

https://github.com/dotnet/corefx/blob/master/src/System.IO.FileSystem/src/System/IO/FileSystem.Unix.cs#L334

[stephentoub]

Yeah, it's a bug that should be fixed.

[karelz]

@marek-safar is it blocking you? Or is 3.0 fix sufficient?

[danmoseley]

Very similar to this we already fixed
https://github.com/dotnet/corefx/issues/32110
https://github.com/dotnet/corefx/pull/32660/files

[marek-safar]

@karelz yes, it's blocking us as it's a regression to .NET/Mono framework functionality

[danmoseley]

@karelz Mono are absorbing more of corefx in 3.0 time frame

[carlossanlop]

I have a fix for this and will submit a PR soon.

Mentioning the area owner @JeremyKuhne.

Explanation:

The behavior differs between Windows and Unix because the function that does the actual move (and unexpected file overwrite in Unix) is the C++ rename function , which has the following remark message in the description:

If newname names an existing file, the function may either fail or override the existing file, depending on the specific system and library implementation.

In Windows, when we attempt to move a file and the destination exists using an Interop function, Windows throws error ERROR_ALREADY_EXISTS = 0xB7, which then we convert into the appropriate exception:

/// File: corefx\src\System.IO.FileSystem\src\System\IO\FileSystem.Windows.cs, line 342:
public static void MoveDirectory(string sourceFullPath, string destFullPath)
{
    if (!Interop.Kernel32.MoveFile(sourceFullPath, destFullPath, overwrite: false))
    {
        int errorCode = Marshal.GetLastWin32Error();
        ...
        ...
        throw Win32Marshal.GetExceptionForWin32Error(errorCode);
    }
}

But in Unix, the Interop function does not fail when the destination file already exists, and we don't do any preemptive checks for the existence of the destFullPath:

/// File: corefx\src\System.IO.FileSystem\src\System\IO\FileSystem.Unix.cs
public static void MoveDirectory(string sourceFullPath, string destFullPath)
{
    if (FileExists(sourceFullPath))
    {
        ...
    }

    if (Interop.Sys.Rename(sourceFullPath, destFullPath) < 0)
    {
        ...
    }
}

Finally, the Interop.Sys.Rename function calls SystemNative_Rename:

// corefx\src\Common\src\Interop\Unix\System.Native\Interop.Rename.cs, line 20:
[DllImport(Libraries.SystemNative, EntryPoint = "SystemNative_Rename", SetLastError = true)]
internal static extern int Rename(string oldPath, string newPath);

And SystemNative_Rename in turn calls the C++ rename function:

// corefx\src\Native\Unix\System.Native\pal_io.c, line 1094:
int32_t SystemNative_Rename(const char* oldPath, const char* newPath)
{
    int32_t result;
    while ((result = rename(oldPath, newPath)) < 0 && errno == EINTR);
    return result;
}

[danmoseley]

Linux man page https://linux.die.net/man/2/rename may be more helpful than the generic C++ std library page. Comes to the same thing, though.

[danmoseley]

When you fix this, we should add it to the list of "potentially breaking changes" in case folks run into it.

[danmoseley]

BTW the "list" is in the platform-compat analyzer
https://github.com/dotnet/platform-compat/tree/cbb1822f5d887e98ccdd903a705d625b2c9ddabc/etc

Unfortunately it has not had much attention for a while, and I am not sure how heavily used it is. If it is broadly useful, we should giev it more attention.

[carlossanlop]

Thank you @danmosemsft. There are 3 files in the location you shared. I have some questions:

1. I suspect the file I have to modify is "exceptions.csv" and I have to add a new exception for linux and osx. Is my assumption correct?

2. What is the net461 file for?

3. I think the change I have to make would look like the one below, but I'm not sure what the last 3 columns mean. I suspect they mean we will be throwing an exception on Linux and OSX from now on. Is my assumption correct?

This is the change I would make:

exceptions.csv

DocId	Namespace	Type	Member	linux	osx	win
M:System.IO.Directory.Move(System.String,System.String)	System.IO	Directory	Move(System.String,System.String)	X	X	X

As a FYI, the other two files have this structure but I suspect we don't care about them for this change:

deprecated.csv

DocId	Namespace	Type	Member	DiagnosticIds

net461.csv

DocId	Namespace	Type	Member

[danmoseley]

@carlossanlop the owner left. I think @joperezr may have worked on it (?) Otherwise do what you think is best - or open an issue there to do it later.

[carlossanlop]

@terrajobst Immo, it seems you've modified the platform-compat files in the past. Could you please confirm if what I stated above is correct?