Main pending issues on Windows.

[Nashwan Mouhammad]

Hello all,

I would like to point out some of the main Windows issues that have been plaguing our efforts towards full Windows integration and ask you guys for any helpful insights you might have to offer towards fixing them.

The main compatibility problems still remaining are the following:

- os.Chmod and (os.File).Chmod:
                  - os.Chmod behaves pretty weirdly considering that Windows is like the opposite of POSIX-compliant when it comes to file permissions.
                  - because there is no direct mapping between classic UNIXy permissions and ACL's done in the os stdlib package, os.Chmod tends to set the file permission to the first digit and, if you were to read the permission, it would show up as that digit, tripled, for example:
                         os.Chmod("C:\\Some\\file.txt", 0700)
                         file, _ := os.Open("C:\\Some\\file.txt")
                         fileInfo, _ := file.Stat()
                         perm := fileInfo.Mode() // will be equal with 0777
                   - (os.File).Chmod, on the other hand, is much more vehement, in that it directly returns an error when called:
                         file, _ := os.Open("C:\\Some\\file.txt")
                         err := file.Chmod(0700) // err will be something like "Chmod not supported by Windows".
For the above, I see no other feasible solution than to get ACL's working in Chmod under Windows and making a "permission translation" layer which properly associates them to their UNIX counterpart.
This will be easier said than done, because even if we get the patch in the golang distribution asap, it might take up to the next official release for the modifications to actually roll out.
For now, we're working towards manually skipping any file permission-related tests on Windows until this is fixed, but it is a problem that is worth bearing in mind.


- files with names with colons trying to be written to disk:
                  - this happens most prevalently in environs/tools, where various release-related files are attempted to be saved under names like
                         "C://Juju//Tools//com.ubuntu.juju:released:tools.json",
                    leading to lookup errors (Windows interpreting everything before the last colon as being the drive label and failing miserably at finding it).

>From what I've understood, this would not be as easy as simply replacing the colons with something else, as there is a direct mapping between these names and the files to be fetched from the main Juju servers, so we'll need to come up with a less direct approach to mitigate this issue.
My colleague Bogdan has been working on a proof of concept of the above (and the below) problem and has a branch here: https://github.com/bogdanteleaga/juju/tree/environs if anyone is interested.


- getting local files through the http package:
                  - this issue has been brought up by my colleague Gabi in an older PR: https://github.com/juju/juju/pull/592/files#diff-62b9de0880bf6d54e453f2653d91da39R84
The point is that there is no way of accessing a file stored on any other drive than "C:\" (which http.Dir("/") defaults to), at least using the functions/methods in the standard http package.
The only place I've managed to find where the creation of a rooted file transport is explicitly done is in the utils package here: https://github.com/juju/utils/blob/master/http.go#L29 , but even changing that to the specific drive letter we need will still cause that particular http.Client with that particular http.Transport to only be able to access files in and ONLY in that specific drive.

I've been rummaging through the /environs/*storage packages for a while now in the vain hope of finding a single point in which this problem could be hacked around; the unfortunate issue being that there are a lot of places where Get's are called on "file://..." urls; some doing so through environs/httpstorage &co, and some doing so directly with calls from the http package.

This is a tough one; our options ranging between creating our own implementation of http (which will inevitably be 95% exactly the same as the original), or doing a huge amount of refactoring; specifically checking for "file://..." urls before each and every Get call and using a simple filesystem read in such cases...


Looking forward to hearing any suggestions you guys might have towards solving any of the above (especially the last two, as they quasi-related and extremely problematic).

Much obliged,
              Nashwan.