I've found this issue while investigating golang/dep#774.

I've found multiple other file related functions implemented outside os (in syscall) that are also affected. According to Naming Files, Paths and Namespaces on MSDN:

These are the directory management functions that no longer have MAX_PATH restrictions if you opt-in to long path behavior: CreateDirectoryW, CreateDirectoryExW GetCurrentDirectoryW RemoveDirectoryW SetCurrentDirectoryW.
These are the file management functions that no longer have MAX_PATH restrictions if you opt-in to long path behavior: CopyFileW, CopyFile2, CopyFileExW, CreateFileW, CreateFile2, CreateHardLinkW, CreateSymbolicLinkW, DeleteFileW, FindFirstFileW, FindFirstFileExW, FindNextFileW, GetFileAttributesW, GetFileAttributesExW, SetFileAttributesW, GetFullPathNameW, GetLongPathNameW, MoveFileW, MoveFileExW, MoveFileWithProgressW, ReplaceFileW, SearchPathW, FindFirstFileNameW, FindNextFileNameW, FindFirstStreamW, FindNextStreamW, GetCompressedFileSizeW, GetFinalPathNameByHandleW.

Here is a list of possible occurrences of this issue (where these functions were called without running the path through os.fixLongPath first:

• syscall.Open: calls CreateFileW
• syscall.Chdir: calls SetCurrentDirectoryW
• syscall.Mkdir: calls CreateDirectoryW
• syscall.Rmdir: calls RemoveDirectoryW
• syscall.Unlink: calls DeleteFileW
• syscall.Rename: calls MoveFileW (os.Rename works fine)
• syscall.UtimesNano: calls CreateFileW
• syscall.Chmod: calls GetFileAttributesW and SetFileAttributesW
• syscall.FullPath: calls GetFullPathNameW

It could possibly occur in os.SameFile since it ends up calling os.*fileStat.loadFileId which attempts CreateFileW without using os.fixLongPath.

I think we previously decided that we aren't adding magic UNC path mangling to the low-level syscall package. If users are using syscall, they can read MSDN docs.

Let's keep this bug specifically about Chmod.

I'm can work on a fix. But I've some questions:

• Since these functions are implemented in syscall, how are they exposed in os? Can we just create a wrapper around them in os that fixes this bug? only 2 of them need fixing.
• syscall.Rename: is duplicated in internal/syscall/windows.Rename. Is there a reason?

edit: Actually, there is a difference. internal/syscall/windows.Rename replaces the destination if it exists, while syscall.Rename fails in that case.

@bradfitz In that case, even os.Remove needs the same fix. I'll submit a CL in a couple of minutes.

Edit: my mistake. I was reading the wrong file. Only os.Chmod is broken.

Remove was already done in 231aa9d. I see:

// Remove removes the named file or directory.                                                                                                                                                                  
// If there is an error, it will be of type *PathError.                                                                                                                                                         
func Remove(name string) error {                                                                       
        p, e := syscall.UTF16PtrFromString(fixLongPath(name))                                          
        if e != nil {                                                                                  
                return &PathError{"remove", name, e}                                                   
        }                                                                                              
...

And Chmod should be just:

diff --git a/src/os/file_posix.go b/src/os/file_posix.go
index 6ee7eeb..5ac0acd 100644
--- a/src/os/file_posix.go
+++ b/src/os/file_posix.go
@@ -48,7 +48,7 @@ func syscallMode(i FileMode) (o uint32) {
 // If the file is a symbolic link, it changes the mode of the link's target.
 // If there is an error, it will be of type *PathError.
 func Chmod(name string, mode FileMode) error {
-       if e := syscall.Chmod(name, syscallMode(mode)); e != nil {
+       if e := syscall.Chmod(fixLongPath(name), syscallMode(mode)); e != nil {
                return &PathError{"chmod", name, e}
        }
        return nil

CL https://golang.org/cl/47010 mentions this issue.