Bug 59893 - Directory.Exists doesn't return the correct result on Mac with case insensitive file system.
Summary: Directory.Exists doesn't return the correct result on Mac with case insensiti...
Alias: None
Product: iOS
Classification: Xamarin
Component: BCL Class Libraries (show other bugs)
Version: XI 11.0 (xcode9)
Hardware: Macintosh Mac OS
: Normal normal
Target Milestone: Xcode9.1
Assignee: Bugzilla
Depends on:
Reported: 2017-10-02 13:55 UTC by David Ingham
Modified: 2017-10-05 10:28 UTC (History)
5 users (show)

See Also:
Is this bug a regression?: No
Last known good build: XI

Sample Project (11.40 KB, application/zip)
2017-10-02 13:58 UTC, David Ingham
Slightly updated test case (17.63 KB, application/zip)
2017-10-02 23:49 UTC, Vincent Dondain [MSFT]

Description David Ingham 2017-10-02 13:55:51 UTC
The directory.exists method isn't returning the correct values when used in iOS simulator on a mac with a case-insensitive file system.

I've replaced the full path with ... for readability but if you run through my attached test scenario on a mac file a case-insensitive file system the following code starts to fail where previously its worked fine..

Creating directory: .../Documents/TestFolder
Checking Path with Directory.Exists: .../Documents/TestFolder
Result: True .../Documents/TestFolder does exist

Checking Path with Directory.Exists: .../DOCUMENTS/TESTFOLDER
Result: False .../DOCUMENTS/TESTFOLDER doesn't exist

Checking Path with Directory.Exists: .../documents/testfolder
Result: False .../documents/testfolder doesn't exist

Despite the fact that documentation says System.IO.Directory.Exits is not case sensitive.

"The path parameter is not case-sensitive."

I've just updated to the following:

=== Visual Studio Community 2017 for Mac ===

Version 7.1.5 (build 2)
Installation UUID: f3a6907d-c3a9-456c-8e01-59ecee1fd01d
	Mono (d15-3/14f2c81) (64-bit)
	GTK+ 2.24.23 (Raleigh theme)

	Package version: 502000224

=== NuGet ===


=== .NET Core ===

Runtime: /usr/local/share/dotnet/dotnet
Runtime Versions:
SDK: /usr/local/share/dotnet/sdk/1.0.4/Sdks
SDK Versions:
MSBuild SDKs: /Library/Frameworks/Mono.framework/Versions/4.8.1/lib/mono/msbuild/15.0/bin/Sdks

=== Xamarin.Profiler ===

Version: 1.5.5
Location: /Applications/Xamarin Profiler.app/Contents/MacOS/Xamarin Profiler

=== Apple Developer Tools ===

Xcode 9.0 (13247)
Build 9A235

=== Xamarin.iOS ===

Version: (Visual Studio Community)
Hash: 152b654a
Branch: xcode9
Build date: 2017-09-15 02:25:56-0400

=== Xamarin.Android ===

Version: (Visual Studio Community)
Android SDK: /Users/david.ingham/Library/Developer/Xamarin/android-sdk-macosx
	Supported Android versions:
		5.1 (API level 22)
		6.0 (API level 23)
		7.0 (API level 24)

SDK Tools Version: 25.2.2 rc1
SDK Platform Tools Version: 24.0.2
SDK Build Tools Version: 23.0.2

Java SDK: /usr
java version "1.8.0_77"
Java(TM) SE Runtime Environment (build 1.8.0_77-b03)
Java HotSpot(TM) 64-Bit Server VM (build 25.77-b03, mixed mode)

Android Designer EPL code available here:

=== Xamarin Inspector ===

Version: 1.3.1
Hash: cbc48dd
Branch: 1.3-release
Build date: Thu, 21 Sep 2017 19:52:53 GMT
Client compatibility: 1

=== Xamarin.Mac ===

Version: (Visual Studio Community)

=== Build Information ===

Release ID: 701050002
Git revision: 7afedcaef8e7542e70e3cf8f9bdb26938b8c0876
Build date: 2017-09-15 08:39:58-04
Xamarin addins: 3262aadf811a18c12eac6742532d052b0139a808
Build lane: monodevelop-lion-d15-3-xcode9

=== Operating System ===

Mac OS X 10.12.6
Darwin 16.7.0 Darwin Kernel Version 16.7.0
    Thu Jun 15 17:36:27 PDT 2017
    root:xnu-3789.70.16~2/RELEASE_X86_64 x86_64
Comment 1 David Ingham 2017-10-02 13:58:40 UTC
Created attachment 25052 [details]
Sample Project
Comment 2 Vincent Dondain [MSFT] 2017-10-02 23:45:26 UTC

I could confirm this issue.

I could get the same output as you with XI

Checking Path: .../Documents/TestFolder
Result: True .../Documents/TestFolder does exist

Result: False .../DOCUMENTS/TESTFOLDER doesn't exist

Checking Path: .../documents/testfolder
Result: False .../documents/testfolder doesn't exist

And this output with the previous XI version:

Checking Path: .../Documents/TestFolder
Result: True .../Documents/TestFolder does exist

Result: True .../DOCUMENTS/TESTFOLDER does exist

Checking Path: .../documents/testfolder
Result: True .../documents/testfolder does exist

Our documentation as you mentioned does seem to specify `System.IO.Directory.Exits` is not case sensitive.

With all that, I'll mark this bug as a regression.
Comment 3 Vincent Dondain [MSFT] 2017-10-02 23:49:18 UTC
Created attachment 25063 [details]
Slightly updated test case

I also made some minor changes to the test case so we do `Console.WriteLine` when the app launches instead of having to click buttons and check a TextView (;
Comment 4 Rolf Bjarne Kvinge [MSFT] 2017-10-03 10:18:58 UTC
This might be an iOS change.

@Vincent, does the test case still fail with XI 11.0 and an iOS 10.3 simulator?
Comment 5 Vincent Dondain [MSFT] 2017-10-04 21:47:20 UTC
It doesn't...

- Works with XI 11.0 on iOS 10.3 sim.
- Fails with XI 11.0 on iOS 11 sim.

Using `XI version:` is irrelevant here it's indeed an iOS 11 issue.

Changing the milestone and importance accordingly.
Comment 6 Rolf Bjarne Kvinge [MSFT] 2017-10-05 05:38:20 UTC
This is by Apple design.

From Xcode 9's release notes (https://developer.apple.com/library/content/releasenotes/DeveloperTools/RN-Xcode/Chapters/Introduction.html):

"Updated Simulator runtimes for iOS 11 and later, tvOS 11 and later, and watchOS 4 and later to treat the filesystem as case sensitive to better simulate physical device behavior. "
Comment 7 David Ingham 2017-10-05 10:28:07 UTC
urgh... doesn't help our legacy resource use case that has mixed case names for resources... If anyone else is bitten by this and can't change the case of the things like we can't the work around i'm using is to create a case sensitive image, mount that and then symbolically link the document folder to that case sensitive image. Then it truly works like it does on the device.

Thanks guys for looking into that :)

Note You need to log in before you can comment on or make changes to this bug.