fix: incorrect check for Windows OS in FileDataStoreFactory

[diesieben07]

The "Windows" part of os.name is not always uppercase. On Windows 10 for example I get "Windows 10", which does not pass the current check. This leads to setPermissionsToOwnerOnly instead of setPermissionsToOwnerOnlyWindows being executed, which then issues the following warning (and does nothing): Unable to set permissions for C:\example, because you are running on a non-POSIX file system

Fixes #953

[elharo]

Any way to test this?

[elharo]

This appears to depend on the default character set.

[diesieben07]

We are just dealing with strings here, they are always in utf-16. Do you mean default locale? If so, I don't think so. The Javadoc for regionMatches does not mention anything about locale and the source code also does not do anything locale dependent.

[diesieben07]

As for testing...
The PR that introduced this check mentions waiting for a windows test machine, which was then apparently addressed in a different PR. I am not familiar with the automated testing setup for this library, but through searching the web I have not been able to find an instance where os.name ever contained "WINDOWS" (all uppercase). So I am not sure how the initial PR even passed testing on any kind of Windows system.

[diesieben07]

See: #557

[elharo]

Case insensitive comparison is fundamentally locale dependent. E.g. I is not the upper case of i in Turkish locales. UTF-16 is a character set, not a locale.

[diesieben07]

UTF-16 is a character set, not a locale.

Yes. Which is why your original message saying "default character set" confused me.

Case insensitive comparison is fundamentally locale dependent. E.g. I is not the upper case of i in Turkish locales.

I know. regionMatches does not take this into account. regionMatches uses Character.toLowerCase, which specifically mentions:

{@code String} case mapping methods can perform locale-sensitive mappings, context-sensitive mappings, and 1:M character mappings, whereas the {@code Character} case mapping methods cannot.

If you prefer i'll change it to a toLowerCase(Locale.ENGLISH) version though.

[elharo]

Yes, that would be good. I still need to think about how to test this.

[diesieben07]

Turns out the implementation in setPermissionsToOwnerOnlyWindows did not actually work (as indicated by the test failures that occurred on Windows).
To me this means that when the original PR happened (#557) it just never got tested, because the IS_WINDOWS check never worked. This caused the Windows test runs to also use setPermissionsToOwnerOnly, which does not fail the tests, it simply logs a warning.

I've fixed obtaining the owning UserPrinicipal, which should also fix the tests on windows.

[elharo]

This is probably just unrelated flakiness but there is a test failure on Java 8:

[INFO] Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.115 s - in com.google.api.client.http.javanet.NetHttpRequestTest
[INFO] Running com.google.api.client.http.javanet.NetHttpTransportTest
[INFO] Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.002 s - in com.google.api.client.http.javanet.NetHttpTransportTest
[INFO] Running com.google.api.client.http.HttpRequestTracingTest
Dec 28, 2019 11:05:15 PM io.opencensus.implcore.trace.RecordEventsSpanImpl finalize
SEVERE: Span Sent.com.google.api.client.http.HttpRequest.execute is GC'ed without being ended.
Dec 28, 2019 11:05:15 PM io.opencensus.implcore.trace.RecordEventsSpanImpl finalize
SEVERE: Span Sent.com.google.api.client.http.HttpRequest.execute is GC'ed without being ended.
[ERROR] Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 8.528 s <<< FAILURE! - in com.google.api.client.http.HttpRequestTracingTest
[ERROR] executeExceptionCreatesSpan(com.google.api.client.http.HttpRequestTracingTest) Time elapsed: 3.528 s <<< FAILURE!
java.lang.AssertionError: expected:<1> but was:<2>
at com.google.api.client.http.HttpRequestTracingTest.executeExceptionCreatesSpan(HttpRequestTracingTest.java:119)

[diesieben07]

I've changed the code to use toLowerCase(Locale.ENGLISH) instead to be more explicit about localization rules.

Not sure why that test failed, it seems to be "unrelated flakyness", like you said.

[MartijnWoudstra]

I'd still love to have this in, since this is blocking my current development

[elharo]

" This caused the Windows test runs to also use setPermissionsToOwnerOnly, which does not fail the tests, it simply logs a warning."

Good detective work. Should this warning be upgraded to an error in the tests somehow?

Also, am I understanding you that the first change in line 56 by itself caused existing tests to fail, and then the additional change in line 160 caused the tests to pass again?

[diesieben07]

Also, am I understanding you that the first change in line 56 by itself caused existing tests to fail, and then the additional change in line 160 caused the tests to pass again?

Correct. The change in line 56 changes Windows to actually use setPermissionsToOwnerOnlyWindows. The original implementation of that method was broken and threw an exception, causing test failures on Windows to now happen.
The change in line 160 fixes setPermissionsToOwnerOnlyWindows to actually work and no longer throw exceptions.

[ghost]

As I'm not used to Github bare with me if this is inappropriate:
Although I understand the reason behind this check and change it's not common in the Windows world to do such specific permission stuff. Usually on a Windows system the NTFS does a good job with its ACLs to "guard" a users home directory from access by other non-Administrators (same as on Unix: if you're Administrator (root) permissions doesn't apply to you) and any other directory is usual on a somewhat semi-read-only. This all started when all that privilege stuff was introduced to normal people when XP was released, wich was based on Win2k and its NT based security model. The "normal user" didn't wanted to struggle about permissions and rights/access management - so Microsoft itself always had it rather loosely and since UAC came with Vista it was, and still is, common practice to just modify ACLs so that just anyone has full access (pretty much like a 777 on Unix) as most stuff struggle with permissions is used by normal home users on a home version of Windows.
TLDR: I don't see that windows specific check and modification useful at all - aside from the fact that when it was implemented at first no Windows box was available for testing. This may will cause more issues in the future as the broken one just because it's done right now.