Determine whether to change Unix behavior when getting time from a non-existent file

[stephentoub]

On Windows, for back-compat reasons, getting CreationTime (and maybe last access/write time, too) from a non-existent file via FileInfo returns the equivalent of DateTime.FromFileTime(0), rather than throwing an exception. On Unix, we do what's arguably the more expected behavior and throw. We should determine whether we want to change the Unix implementation to match what's there on Windows.

[ianhays]

I'd agree that the two implementations should function the same if at all possible. Now whether that means make them both throw or both return DateTime.FromFileTime(0), I'm not sure.

If keeping the Windows implementation as it currently stands is a necessity, then I vote we modify the Unix implementation to follow suit. If not, I think they should both throw.

Same for dotnet/corefx#2369 for Directory/DirectoryInfo

[ianhays]

Design review feedback leaned towards allowing Unix to have a different behavior than Windows because of the Windows-specific notions of FromFileTime, though it wasn't entirely conclusive. Changing the Windows behavior is not what we want to do because of the breaking change it would cause, so the best option is different behaviors on different systems.

Returning the windows 0 time on a Unix machine wouldn't make any sense and returning the Unix 0 time would still be inconsistent with the Windows 0 time, so the better alternative of throwing an exception is chosen.

[polarapfel]

@ianhays

I've run into issues with how FileInfo and FileSystemInfo deal with non-existent files and FileInfo instances representing them across Windows and Linux.

Consider this:

try 
{
  var doesNotExist = new FileInfo(fullPathToFileThatDoesNotExist);
  // e.g. /pathThatExists/pathThatDoesNotExist/FileThatDoesNotExist
  if (configFileInfo.Length == 0) { return false; }
  else { return true; }
}
catch (FileNotFoundException)
{
// This is thrown on Windows.
return false;
}
catch (DirectoryNotFoundException)
{
// This is thrown on Linux.
return false;
}

The same condition exists on both platforms, the same API is called, yet I get two different exception types being thrown.

Can this be fixed and in both cases the same exception is thrown?

How about throwing DirectoryNotFoundException when a partial path in the full path to the file that doesn't exist already is not present in the file system.

If the path leading up to the file not existing is present in the file system, throw a FileNotFoundException.

Good idea?

thanks,

Tobias