Bug 37478 - System.IO.File.Exists can return false even when the file exists if the directory name is too long
Summary: System.IO.File.Exists can return false even when the file exists if the direc...
Status: CONFIRMED
Alias: None
Product: Runtime
Classification: Mono
Component: io-layer (show other bugs)
Version: 4.2.0 (C6)
Hardware: PC Windows
: --- normal
Target Milestone: ---
Assignee: Bugzilla
URL:
Depends on:
Blocks:
 
Reported: 2016-01-07 15:34 UTC by Fluendo dev team
Modified: 2016-01-08 19:35 UTC (History)
3 users (show)

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


Attachments

Description Fluendo dev team 2016-01-07 15:34:49 UTC
With the latest public mono release in Windows, xbuild's ResolveHintPath is failing to resolve ICSharpCode.SharpZipLib.Portable.dll reference because File.Exists return false for an existing path:

 For searchpath {HintPathFromItem}
                Considered ..\packages\SharpZipLib.Portable.0.86.0.0003\lib\portable-net45+netcore45+wp8+win8+wpa81+MonoTouch+MonoAndroid+Xamarin.iOS10\ICSharpCode.SharpZipLib.Portable.dll, but it does not exist.


I have created a very simple test case that calls:
  System.Console.WriteLine (System.IO.File.Exists(args[0]));

With the following bogus result:

$ mono Test ../packages/SharpZipLib.Portable.0.86.0.0003/lib/portable-net45+netcore45+wp8+win8+wpa81+MonoTouch+MonoAndroid+Xamarin.iOS10/ICSharpCode.SharpZipLib.Portable.dll
False

$ ls -al ../packages/SharpZipLib.Portable.0.86.0.0003/lib/portable-net45+netcore45+wp8+win8+wpa81+MonoTouch+MonoAndroid+Xamarin.iOS10/ICSharpCode.SharpZipLib.Portable.dll
-rwxr-xr-x 1 fluendo Administrators 183808 Jan  7 11:46 ../packages/SharpZipLib.Portable.0.86.0.0003/lib/portable-net45+netcore45+wp8+win8+wpa81+MonoTouch+MonoAndroid+Xamarin.iOS10/ICSharpCode.SharpZipLib.Portable.dll


I can only reproduce the issue when there is a folder with a long name like "portable-net45+netcore45+wp8+win8+wpa81+MonoTouch+MonoAndroid+Xamarin.iOS10"
Comment 1 Fluendo dev team 2016-01-07 15:40:46 UTC
$ mono.exe --version
Mono JIT compiler version 4.2.1 (Visual Studio built mono)
Copyright (C) 2002-2014 Novell, Inc, Xamarin Inc and Contributors. www.mono-project.com
        TLS:           normal
        SIGSEGV:       normal
        Notification:  Thread + polling
        Architecture:  x86
        Disabled:      none
        Misc:          softdebug
        LLVM:          supported, not enabled.
        GC:            sgen
Comment 2 Aleksey Kliger 2016-01-07 20:48:20 UTC
Could not reproduce on Windows 8.1 using Mono 4.2.1.102.  Created the same directory structure as in Comment 0, ran the following example program:

---
using System;

class Repro37478 {
	public static void Main (string[] args)
	{
		Console.WriteLine("Checking if [{0}] exists", args[0]);
		Console.WriteLine(System.IO.File.Exists(args[0]));
		return;
	}
}
---

(Tried both \ and / for path separator).
Comment 3 Fluendo dev team 2016-01-08 11:08:33 UTC
Hi,

I have narrowed down a bit more the issue, it only happens if the paths starts with ../ and only with Mono, .NET's runtime does not have the same issue.

Mono without ../

fluendo@botbinado /home/fluendo/longomatch-nigthly/sources/windows_x86/longomatch-git-master/
 mono Test packages/SharpZipLib.Portable.0.86.0.0003/lib/portable-net45+netcore45+wp8+win8+wpa81+MonoTouch+MonoAndroid+Xamarin.iOS10/ICSha rpCode.SharpZipLib.Portable.dll
True

Mono with ../
fluendo@botbinado /home/fluendo/longomatch-nigthly/sources/windows_x86/longomatch-git-master/LongoMatch.DB
$ mono Test ../packages/SharpZipLib.Portable.0.86.0.0003/lib/portable-net45+netcore45+wp8+win8+wpa81+MonoTouch+MonoAndroid+Xamarin.iOS10/IC SharpCode.SharpZipLib.Portable.dll
False

.NET with ../
fluendo@botbinado /home/fluendo/longomatch-nigthly/sources/windows_x86/longomatch-git-master/LongoMatch.DB
$ ./Test.exe ../packages/SharpZipLib.Portable.0.86.0.0003/lib/portable-net45+netcore45+wp8+win8+wpa81+MonoTouch+MonoAndroid+Xamarin.iOS10/I CSharpCode.SharpZipLib.Portable.dll
True


My first test was with a Msys console but I can reproduce it with MS-DOS too
Comment 4 Aleksey Kliger 2016-01-08 15:50:42 UTC
The interesting bit here is that your cwd is pretty long, too.  cwd concatenated with the "../etc" path is 250 characters.  My reproduction was on a considerably shorter cwd.  Let me see what I can learn.
Comment 5 Aleksey Kliger 2016-01-08 19:35:16 UTC
This is due to the windows 260 character MAX_PATH limit.

The (admittedly unsatisfying) workaround is to use a shorter directory name.

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