Unify File.Replace Unix and Windows exception throwing behavior

[mikernet]

Description

using (File.Create("test.txt")) {}
Directory.CreateDirectory("test");
			
// Correct - throws IOExeption with message "Is a directory"
File.Replace("test.txt", "test", null);

// Incorrect = throws IOExeption with message "Not a directory"
File.Replace("test", "test.txt", null);

Configuration

.NET 5 on Linux.

[tmds]

These errors come from rename.

// Incorrect = throws IOExeption with message "Not a directory"
File.Replace("test", "test.txt", null);

leads to

       ENOTDIR
              A component used as a directory in oldpath or newpath is
              not, in fact, a directory.  Or, oldpath is a directory,
              and newpath exists but is not a directory.

@mikernet what would be a more appropriate message?

[mikernet]

The issue is that it is a directory, not that it's not a directory, so the same error message should be showing up for both those cases (i.e. the correct case one), no?

[mikernet]

Oh wait...this is a bit of an odd inconsistency, but File.Replace on unix works on directories, but does not in windows, so I guess it kinda makes sense that it's saying "not a directory" - it's trying to replace one directory with a another but finding a file.

There are a lot of inconsistencies in the IO API like this between unix and windows. For example, Windows throws UnauthorizedAccessException when some file ops are attempted on dirs, but unix throws IOException.

I'm trying to eliminate all of these sorts of inconsistencies in my file system lib but would it make sense to try to keep things more consistent across platforms in the BCL? If File.Replace doesn't work on directories in windows then I don't think it should in unix either.

[danmoseley]

Incidentally in pulling up this code I noticed we use the wrong path in this error message
https://github.com/dotnet/runtime/blob/main/src/libraries/System.IO.FileSystem/src/System/IO/FileSystem.Unix.cs#L126
I'll see if I can fix that.

[mikernet]

Just edited my message above right after you posted yours with some more details.

[mikernet]

TBH the UnauthorizedAccessException that is thrown on windows with a very unhelpful error message when you try to do a file op on a dir path doesn't make any sense. I convert those into FileNotFound exceptions in my lib. That said, idk what the appetite is for making a technically breaking change in this area.

[danmoseley]

As an experiment I looked at the IOExceptions thrown and caught in many of the S.IO.FileSystem tests. Many of them do not contain the file paths. In some cases that can be fixed fairly easily. In some other cases, it's difficult to know which path the problem applied to (eg was access denied to source or destination).
This doesn't directly address the issue reported here, just noted.

[mikernet]

This method also has inconsistent behavior between Windows and Unix - on Windows, if the source and destination file are the same it throws an exception. On Unix it works fine and still copies the contents of the file to the backup file.

[tmds]

Summarizing the inconsistencies reported by @mikernet:

• The method should fail when the source is a directory.
• The method should fail when source and destination are the same file.

These cases are described in the docs to throw UnauthorizedAccessException and IOException respectively.