os: MkdirAll fails when creating top-level UNC paths on Windows

[Zillode]

Go 1.4, Windows

When the top-level folder of a Windows UNC path does not exist, the os.MkdirAll function goes one step too deep in recursion. This is illustrated in the following scenario:

1. Make sure C:\Test does not exist
2. Try to create a new folder with arbitrary depth os.MkdirAll("\\\\?\\C:\\Test", 0700) using UNC (we use UNC to support long paths).
3. This fails with The filename, directory name, or volume label syntax is incorrect. This is due to a bug in the Go library. The callstack reveals that it tries to create the folder \\?, which should not happen.

(Related to syncthing/syncthing#1822)

[minux]

See also #3358. If you want to use UNC paths to workaround path length constrains, you'd better to implement your own MkdirAll.

[minux]

See also #3358. If you want to use UNC paths to workaround path length constrains, you'd better to implement your own MkdirAll.

[Zillode]

I figured this issue is different because we use explicitly use the UNC paths (where #3358 tries to automatically support long paths for all functions).
We'll implement a custom MkdirAll if this seems out of scope for the moment, thanks.

[Zillode]

I figured this issue is different because we use explicitly use the UNC paths (where #3358 tries to automatically support long paths for all functions).
We'll implement a custom MkdirAll if this seems out of scope for the moment, thanks.

[DmitriyMV]

@minux @ianlancetaylor I think it's a predecessor of #22230 and can be safely closed.

[DmitriyMV]

@minux @ianlancetaylor I think it's a predecessor of #22230 and can be safely closed.

[bradfitz]

@DmitriyMV, thanks, closing. Fixed by 7a1347a

[bradfitz]

@DmitriyMV, thanks, closing. Fixed by 7a1347a