Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
DirectoryInfo.MoveTo and Directory.Move mistakenly prevent renaming directories to case variations of themselves on Windows, macOS #40013
The default filesystems on macOS and Windows are case-insensitive, yet case-preserving.
Therefore, renaming a filesystem item to a case variation of its current name - e.g.,
You can paste following snippet directly into a
using System.IO; Environment.CurrentDirectory = Path.GetTempPath(); Directory.CreateDirectory("foo"); // This should succeed even on macOS and Windows, but throws an exception. // System.DirectoryInfo.MoveTo() exhibits the same symptom. Directory.Move("foo", "FOO");
Additionally: Even if the source and destination are truly identical, it is arguably more sensible to apply desired-state logic and perform a quiet no-op rather than throwing an exception.
Thanks for the report. The code does check case insensitively if a file written to temp can be retrieved case insensitively:
Is there a bug here? Of course, it will go wrong if the file system you are using has a different case sensitivity to the filesystem containing the temp folder.
Possibly this is another case where we should let the OS do the checks, similar to how we removed checks for invalid characters in the path.
@danmosemsft: Yes, there is a bug:
On a case-preserving filesystem - even if access to files is case-insensitive - I should still be able to rename my
Deferring to the OS seems like a good idea (
(Whether a static, process-global check for case-sensitivity based on a single location is sufficient, is a separate matter - I haven't looked into this, and I don't know if a given OS can access a mix of case-sensitive and case-insensitive volumes.)
As stated, If the paths are truly identical, to me the most sensible behavior is a quiet no-op - and if
In short: simply deferring to the OS may solve the problem in more than one way:
I'm fine with allowing this. I think there may already be an issue on this actually- I'll try and see if I can find it. I'd rather not remove the failure case if the strings are ordinally equal.
It is a breaking change, so we'll have to document it as such.
Marking as up-for-grabs if anyone wants to take it on. We would want tests to validate that this works correctly with just a casing change. There should be tests with directory content as well.
Glad to hear it, @JeremyKuhne.
Understood, but note that this means preserving the existing asymmetry between files and directories, given that ordinally equal file names result in a quiet no op, on all platforms.
If you retain the behavior of failing with ordinally equal strings with directories, I would consider this a mere bug fix, but it is certainly worth documenting either way.
Yeah, and I don't like that. If there was any extra value beyond that and it wasn't breaking I'd be more inclined to do it. If someone wants to investigate how this change impacts PowerShell that data might help make this part of the decision clearer (i.e. do they do any validation before calling this method, particularly from their "move" commands)?
The filesystem-item move functionality is in
The short of it is: Aside from preparatory path normalization and translating PS-drive-based paths into "native ones":
That is, changing the CoreFx behavior to making ordinally equal directory paths result in a quiet no-op would surface in PowerShell's