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.
--
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju-dev
