I've been writing some code which involves syncing files (like
rsync) and it became apparent that under Linux I could read
modification times (os.Lstat) with nanosecond precision but
only write them with microsecond precision. This difference
in precision is rather annoying when trying to discover
whether files need syncing or not!
I've patched syscall and os to increases the accuracy of of
os.Chtimes for Linux and Windows. This involved exposing the
utimensat system call under Linux and a bit of extra code
under Windows. I decided not to expose the "at" bit of the
system call as it is impossible to replicate under Windows, so
the patch adds syscall.Utimens() to all architectures along
with a ImplementsUtimens flag.
If the utimensat syscall isn't available (utimensat was added
to Linux in 2.6.22, Released, 8 July 2007) then it silently
falls back to the microsecond accuracy version it uses now.
The improved accuracy for Windows should be good for all
versions of Windows.
Unfortunately Darwin doesn't seem to have a utimensat system
call that I could find so I couldn't implement it there. The
BSDs do, but since they share their syscall implementation
with Darwin I couldn't figure out how to define a syscall for
*BSD and not Darwin. I've left this as a TODO in the code.
In the process I implemented the missing methods for Timespec
under Windows which I needed which just happened to round out
the Timespec API for all platforms!
------------------------------------------------------------
Test code: http://play.golang.org/p/1xnGuYOi4b
Linux Before (1000 ns precision)
$ ./utimetest.linux.before z
Setting mtime 1344937903123456789: 2012-08-14 10:51:43.123456789 +0100 BST
Reading mtime 1344937903123457000: 2012-08-14 10:51:43.123457 +0100 BST
Linux After (1 ns precision)
$ ./utimetest.linux.after z
Setting mtime 1344937903123456789: 2012-08-14 10:51:43.123456789 +0100 BST
Reading mtime 1344937903123456789: 2012-08-14 10:51:43.123456789 +0100 BST
Windows Before (1000 ns precision)
X:\>utimetest.windows.before.exe c:\Test.txt
Setting mtime 1344937903123456789: 2012-08-14 10:51:43.123456789 +0100 GMTDT
Reading mtime 1344937903123456000: 2012-08-14 10:51:43.123456 +0100 GMTDT
Windows After (100 ns precision)
X:\>utimetest.windows.after.exe c:\Test.txt
Setting mtime 1344937903123456789: 2012-08-14 10:51:43.123456789 +0100 GMTDT
Reading mtime 1344937903123456700: 2012-08-14 10:51:43.1234567 +0100 GMTDT
R=golang-dev, alex.brainman, rsc, bradfitz
CC=golang-dev
https://golang.org/cl/6905057
Thank you zhoumichaely for original CL 5175042.
Fixes#1740.
Fixes#2315.
R=golang-dev, bradfitz, mikioh.mikioh
CC=golang-dev, zhoumichaely
https://golang.org/cl/6822045
It is common to close network connection while another goroutine is
blocked reading on another goroutine. This sequence corresponds to
windows calls to WSARecv to start io, followed by GetQueuedCompletionStatus
that blocks until io completes, and, finally, closesocket called from
another thread. We were expecting that closesocket would unblock
GetQueuedCompletionStatus, and it does, but not always
(http://code.google.com/p/go/issues/detail?id=4170#c5). Also that sequence
results in connection is being reset.
This CL inserts CancelIo between GetQueuedCompletionStatus and closesocket,
and waits for both WSARecv and GetQueuedCompletionStatus to complete before
proceeding to closesocket. This seems to fix both connection resets and
issue 4170. It also makes windows code behave similar to unix version.
Unfortunately, CancelIo needs to be called on the same thread as WSARecv.
So we have to employ strategy we use for connections with deadlines to
every connection now. It means, there are 2 unavoidable thread switches
for every io. Some newer versions of windows have new CancelIoEx api that
doesn't have these drawbacks, and this CL uses this capability when available.
As time goes by, we should have less of CancelIo and more of CancelIoEx
systems. Computers with CancelIoEx are also not affected by issue 4195 anymore.
Fixes#3710Fixes#3746Fixes#4170
Partial fix for issue 4195
R=golang-dev, mikioh.mikioh, bradfitz, rsc
CC=golang-dev
https://golang.org/cl/6604072
This is a part of a bigger change that adds data race detection feature:
https://golang.org/cl/6456044
The purpose of this patch is to provide coarse-grained synchronization
between all Read() and Write() calls.
R=rsc, bradfitz, alex.brainman
CC=golang-dev
https://golang.org/cl/6610064
Since NUL usually terminates strings in underlying syscalls, allowing
it when converting string arguments is a security risk, especially
when dealing with filenames. For example, a program might reason that
filename like "/root/..\x00/" is a subdirectory or "/root/" and allow
access to it, while underlying syscall will treat "\x00" as an end of
that string and the actual filename will be "/root/..", which might
be unexpected. Returning EINVAL when string arguments have NUL in
them makes sure this attack vector is unusable.
R=golang-dev, r, bradfitz, fullung, rsc, minux.ma
CC=golang-dev
https://golang.org/cl/6458050
This slipped in with the implementation of Getpid in CL 5909043.
I'd exclude that CL entirely but it is tangled up in the Win32finddata changes.
R=golang-dev, minux.ma
CC=golang-dev
https://golang.org/cl/6297065
Preserve old API by using correct struct in system call
and then copying the results, as we did for SetsockoptLinger.
R=golang-dev, bradfitz
CC=golang-dev
https://golang.org/cl/6307065
This moves the various CA root fetchers from crypto/tls into crypto/x509.
The move was brought about by issue 2997. Windows doesn't ship with all
its root certificates, but will instead download them as-needed when using
CryptoAPI for certificate verification.
This CL changes crypto/x509 to verify a certificate using the system root
CAs when VerifyOptions.RootCAs == nil. On Windows, this verification is
now implemented using Windows's CryptoAPI. All other root fetchers are
unchanged, and still use Go's own verification code.
The CL also fixes the hostname matching logic in crypto/tls/tls.go, in
order to be able to test whether hostname mismatches are honored by the
Windows verification code.
The move to crypto/x509 also allows other packages to use the OS-provided
root certificates, instead of hiding them inside the crypto/tls package.
Fixes#2997.
R=agl, golang-dev, alex.brainman, rsc, mikkel
CC=golang-dev
https://golang.org/cl/5700087
syscall_windows.go contains a small demo, which calls the obsolete
syscall.Errstr function.
R=golang-dev, alex.brainman
CC=golang-dev
https://golang.org/cl/5475044
For now a pair of socket options SOL_SOCKET and SO_BINDTODEVICE
is supported on Linux only. I'd like to demote BindToDevice API
to syscall level because it's Linux dependent one.
In the near future, probably we may have a bit more portable
API that using IPROTO_IP/IPV6 level socket options to specify,
identify an inbound, outbound IP interface on incoming, outgoing
UDP and raw IP packets.
R=cw, golang-dev
CC=golang-dev
https://golang.org/cl/5447071
The environment is needed by package time, which
we want not to depend on os (so that os can use
time.Time), so push down into syscall.
Delete syscall.Sleep, now unnecessary.
The package os environment API is preserved;
it is only the implementation that is moving to syscall.
Delete os.Envs, which was undocumented,
uninitialized on Windows and Plan 9, and
not maintained by Setenv and Clearenv.
Code can call os.Environ instead.
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/5370091
- syscall (not os) now defines the Errno type.
- the low-level assembly functions Syscall, Syscall6, and so on
return Errno, not uintptr
- syscall wrappers all return error, not uintptr.
R=golang-dev, mikioh.mikioh, r, alex.brainman
CC=golang-dev
https://golang.org/cl/5372080
New DLL and Proc types to manage and call dll functions. These were
used to simplify syscall tests in runtime package. They were also
used to implement LazyDLL and LazyProc.
LazyProc, like Proc, now have Call function, that just a wrapper for
SyscallN. It is not as efficient as Syscall, but easier to use.
NewLazyDLL now supports non-ascii filenames.
LazyDLL and LazyProc now have Load and Find methods. These can be used
during runtime to discover if some dll functions are not present.
All dll functions now return errors that fit os.Error interface. They
also contain Windows error number.
Some of these changes are suggested by jp.
R=golang-dev, jp, rsc
CC=golang-dev
https://golang.org/cl/5272042
I don't know the protocol regarding the zsyscall files which appear to
be hand-generated, so I've re-done them and added them to the change.
R=rsc, alex.brainman, nigeltao
CC=golang-dev
https://golang.org/cl/4975060
Before this change, syscall package would load
all dlls used anywhere in the go tree on startup.
For example, this program:
package main
import "fmt"
func main() {
fmt.Printf("Hello world\n")
}
would load these dlls
kernel32.dll
advapi32.dll
shell32.dll
wsock32.dll
ws2_32.dll
dnsapi.dll
iphlpapi.dll
Most of these dlls are network related and are not used
in this program. Now the same program loads only
kernel32.dll
shell32.dll
This decreases start times somewhat.
This also relaxes the rules of which dlls can be included
in the standard library. We could now include system calls
that are not available on all versions of Windows, because
we could decide if we should call them during runtime.
R=rsc, vcc.163
CC=golang-dev
https://golang.org/cl/4815046
