--create-dirs fails when run as system

[mbeifuss]

Commit f16bed0 broke the ability to use the --create-dirs to create folders from a service running as system (not sure if that is a unique case or not). The service calls curl The command below fails with this change, reverting the change fixes the issue.
"C:\Program Files (x86)\curl\curl.exe" -k -L -o "D:\temp\system\curl.exe.tmp" -D "D:\temp\system\curl.exe.hdr" --create-dirs https://10.10.1.1/Download/curl.exe, creates the folder but then errors out and fails to download the file(s) this is whether the folder(s) existed or not.
We are calling curl from the service via CreateProcess(exeName, argList, &saProc, &saThread,
FALSE, CREATE_BREAKAWAY_FROM_JOB, NULL, NULL, &si, &piProc);

I did this

"C:\Program Files (x86)\curl\curl.exe" -k -L -o "D:\temp\system\curl.exe.tmp" -D "D:\temp\system\curl.exe.hdr" --create-dirs https://10.10.1.1/Download/curl.exe

I expected the following

folder temp\system to be created and curl.exe to be downloaded into it. Folder does get created but then it fails to download the file and errors with the message You don't have permission to create D:.

curl/libcurl version

7.64.0
[curl -V output]
curl 7.64.0 (i386-pc-win32) libcurl/7.64.0 OpenSSL/1.1.1a (Schannel) zlib/1.2.11 brotli/1.0.7 WinIDN libssh2/1.8.0 nghttp2/1.36.0
Release-Date: 2019-02-06
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp scp sftp smb smbs smtp smtps telnet tftp
Features: AsynchDNS IDN IPv6 Largefile SSPI Kerberos SPNEGO NTLM SSL libz brotli TLS-SRP HTTP2 HTTPS-proxy MultiSSL

operating system

Windows 10

[jay]

Confirmed, it's a directory traversal issue. I'm on it.

[jay]

Please try #4797.

create_dir_hierarchy erroneously attempts to create the drive's current directory which may not exist, and if it does exist may be access denied. This is specific to Windows/MSDOS which stores a per-process table of drives and their current directories. For example your outfile D:\temp\system\curl.exe.tmp is broken down and mkdir called on each token:

dirbuildup: D:
dirbuildup: D:\temp
dirbuildup: D:\temp\system

D: represents the current directory so it's calling mkdir D: which could be D:\foo\bar or whatever for all we know. Although in this case we'll assume it's actually D:\ which would cause access denied. Prior versions of curl work because they ignored access denied errors and allowed for directory traversal, which is acceptable with the outfile path. The changes I made restore that behavior (without the race condition whose fix caused this regression) and also I added a check for current directory drives to skip them. In other words no longer mkdir D: there's no reason for that.