1

In my .Net desktop app, I have several routines relying on System.IO.File.Exists.

Apparently, System.IO.File.Exists "becomes", somehow, case-sensitive (!!) when the file being checked is located under the Google Drive File Stream (G:) drive. That's obviously not what is really happening, but the result is the same.

All of a sudden the casing of the path I am constructing then throwing to File.Exists becomes important; however, I cannot rely on that, as our prefix and extension casing may vary (which has always been fine on Windows AFAIK).

Java has the same problem, obviously (I tested).

QUESTION

Ever heard of that? Any workaround or fix? Is there an equivalent method that I could use in the Google API? Seems overkill to bring in the Google API just for a few calls here and there, but if I have to...

UPDATE

I reported the issue to Google and after quite a lot of discussions with their support team, the engineering has finally acknowledged the problem, and will address it shortly.

CTZStef
  • 1,675
  • 2
  • 18
  • 47
  • 1
    File.Exists is neither case sensitive nor case insensitive, it simply punts the question to the underlying file system and this file system may be either. So if the file system that File Stream sets up in order to support "stream on demand" is case sensitive, then that is why you get this answer. – Lasse V. Karlsen Sep 08 '17 at 10:52
  • 1
    In other words, unless Google made an error when creating this file system, this could be both correct and by-design and not-something-you-can-change. In other words, your application may be wrong if it assumes it can mix and match casing for filenames and folders and hope this is working. – Lasse V. Karlsen Sep 08 '17 at 10:53
  • I agree @LasseV.Karlsen however, that's the way File.Exists has been working on Windows for ages (ok, years), so I wouldn't expect its behavior to change with Google Drive File Stream, in the sense that the case-insensitive behavior is the expected behavior on Windows platform. I'd bet I am not the only one making this assumption. – CTZStef Sep 15 '17 at 21:38
  • No, I think you misunderstand. The fact that the NTFS and FATx file systems are case insensitive is not a guarantee that Microsoft or Windows has made, it is a choice for **those** file systems. A different file system can opt to be case sensitive if it chooses. Nobody has guaranteed that all file systems attached to a Windows installation will be case insensitive. Basically, there is no error here, other than you and/or your program has assumed that all file systems are case insensitive. – Lasse V. Karlsen Sep 18 '17 at 19:07
  • As for "nobody cares", well, it's an old issue, see https://stackoverflow.com/questions/7199039/file-paths-in-windows-environment-not-case-sensitive – Lasse V. Karlsen Sep 18 '17 at 19:08
  • I strongly disagree: if Google went as far as creating a G: drive (just like C:, D:, ...) that shows up on my computer, well then at the very least this drive should follow Windows' file systems (either NTFS or FAT) and their file casing insensitiveness. It does not make much sense otherwise. This is poor interoperability. – CTZStef Sep 18 '17 at 19:26
  • About your link: "Yes. Windows ... file systems, ... are case insensitive (normally) (sic). The underlying implementation of a network file system may be case sensitive, however, most software that allows Windows to access it will automatically make case sensitive file systems appear as case insensitive to Windows." And then, do you really believe I am the only one to rely on File.Exists and to count on Windows case-insensitivity in a desktop Windows-only app? – CTZStef Sep 18 '17 at 19:40

0 Answers0