diff options
| author | Alex Brainman <alex.brainman@gmail.com> | 2017-04-27 17:43:33 +1000 |
|---|---|---|
| committer | Alex Brainman <alex.brainman@gmail.com> | 2017-05-07 01:26:02 +0000 |
| commit | 53003621720ff39c4745a76f76847123c27b01ea (patch) | |
| tree | 21cf082bce25fc5afcb639dff6c2c7c1d876c44b /src/bytes/buffer.go | |
| parent | e94b9d41432a0560328c786b908e59c27a0a6c47 (diff) | |
| download | go-53003621720ff39c4745a76f76847123c27b01ea.tar.xz | |
os: reimplement windows os.Stat
Currently windows Stat uses combination of Lstat and Readlink to
walk symlinks until it reaches file or directory. Windows Readlink
is implemented via Windows DeviceIoControl(FSCTL_GET_REPARSE_POINT, ...)
call, but that call does not work on network shares or inside of
Docker container (see issues #18555 ad #19922 for details).
But Raymond Chen suggests different approach:
https://blogs.msdn.microsoft.com/oldnewthing/20100212-00/?p=14963/
- he suggests to use Windows I/O manager to dereferences the
symbolic link.
This appears to work for all normal symlinks, but also for network
shares and inside of Docker container.
This CL implements described procedure.
I also had to adjust TestStatSymlinkLoop, because the test is
expecting Stat to return syscall.ELOOP for symlink with a loop.
But new Stat returns Windows error of ERROR_CANT_RESOLVE_FILENAME
= 1921 instead. I could map ERROR_CANT_RESOLVE_FILENAME into
syscall.ELOOP, but I suspect the former is broader than later.
And ERROR_CANT_RESOLVE_FILENAME message text of "The name of
the file cannot be resolved by the system." sounds fine to me.
Fixes #10935
Fixes #18555
Fixes #19922
Change-Id: I979636064cdbdb9c7c840cf8ae73fe2c24499879
Reviewed-on: https://go-review.googlesource.com/41834
Reviewed-by: Harshavardhana <hrshvardhana@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Diffstat (limited to 'src/bytes/buffer.go')
0 files changed, 0 insertions, 0 deletions
