<p>Updating to the latest Git bash, which included <code>curl v8.x</code> fixed the issue.</p>

CC BY-SA 4.0
2023-06-09T20:33:20.790Z
2023-06-09T20:33:20.790Z
Chris F
<p>This could be the common known issue based on the upload transfer of binary files using the <code>curl</code> command on Windows.</p>
<p>By default, <code>curl</code> on a Windows device uses ASCII transfer mode which can cause issues with binary files like <code>.zip</code> archives. Whereas on a Mac device, the <code>curl</code> command uses binary transfer mode as default.</p>
<p>To avoid this, override the ASCII transfer method by implicitly specifying the  transfer mode as binary, by using the <code>--ftp-binary</code> option.</p>
<p>See amended command below:</p>
<pre><code>$ curl -T ./build_artifact.zip -u 'user:password' ftp://ftp.company.com/devops/test/build_artifact.zip --ftp-ssl-reqd --ftp-create-dirs -k --ftp-binary

</code></pre>

CC BY-SA 4.0
2023-05-30T14:25:11.397Z
I was hoping this would work. But I get `curl: option --ftp-binary is unknown`. Maybe later versions of `curl` have it, but apparently not `curl v7.x`.
Chris F
CC BY-SA 4.0
2023-05-27T12:19:15.277Z
2023-05-27T12:54:34.677Z
2023-05-27T12:54:34.677Z
djmonki
<p>Per our IT department, I have to use a curl command to upload files to our SFTP server.</p>
<p>I use a Jenkins pipeline to build our artifacts on Windows build nodes, which are <code>*.zip</code> files, and this is the <code>curl</code> command I use</p>
<pre class="lang-shell prettyprint-override"><code>C:\&gt; curl -V
curl 7.03.1 (Windows) libcurl/7.03.1 Schannel

C:\&gt; curl -T ./build_artifact.zip -u 'user:password'  ftp://ftp.company.com/devops/test/build_artifact.zip --ftp-ssl-reqd --ftp-create-dirs -k
</code></pre>
<p>The file uploads correctly.</p>
<p>But when I download the file on my Mac and I unzip it, I get</p>
<pre><code>$ unzip build_artifact.zip
Archive:  build_artifact.zip
  End-of-central-directory signature not found.  Either this file is not
  a zipfile, or it constitutes one disk of a multi-part archive.  In the
  latter case the central directory and zipfile comment will be found on
  the last disk(s) of this archive.
unzip:  cannot find zipfile directory in one of build_artifact.zip or
        build_artifact.zip.zip, and cannot find build_artifact.zip.ZIP, period.
</code></pre>
<p>Note if I execute the same <code>curl</code> command on my Mac to upload to the SFTP site, I can readily unzip the artifact when I subsequently download it.</p>
<p>Any clues on why this happens, and how to fix it?</p>

CC BY-SA 4.0
2023-05-22T19:53:41.230Z
Is there any chance the source path would differ on the build server? `./build_artifact.zip` for example, might the command be running from a different start folder, which means the relative path doesn't point to a file?

One quick check for this would be to look at the size of the file. If it's 0 bytes, you might be uploading "file not found", if that makes sense.
Fenton
CC BY-SA 4.0
2023-05-22T21:12:45.457Z
Thanks. It's the same file. I did check the file size and it's the same. On my scripts, I do a `dir(env.WORKSPACE) {}` before I execute the `curl` command, and the `WORKSPACE` is where the `build_artifact.zip` file is.
Chris F
<windows><curl>
Windows curl command corrupts zip files on upload to SFTP server
Chris F
# Windows curl command corrupts zip files on upload to SFTP server

(Asked by: username_0 on 2023-05-22)

Per our IT department, I have to use a curl command to upload files to our SFTP server.
I use a Jenkins pipeline to build our artifacts on Windows build nodes, which are *.zip files, and this is the curl command I use
C:\> curl -V
curl 7.03.1 (Windows) libcurl/7.03.1 Schannel

C:\> curl -T ./build_artifact.zip -u 'user:password'  ftp://ftp.company.com/devops/test/build_artifact.zip --ftp-ssl-reqd --ftp-create-dirs -k

The file uploads correctly.
But when I download the file on my Mac and I unzip it, I get
$ unzip build_artifact.zip
Archive:  build_artifact.zip
  End-of-central-directory signature not found.  Either this file is not
  a zipfile, or it constitutes one disk of a multi-part archive.  In the
  latter case the central directory and zipfile comment will be found on
  the last disk(s) of this archive.
unzip:  cannot find zipfile directory in one of build_artifact.zip or
        build_artifact.zip.zip, and cannot find build_artifact.zip.ZIP, period.

Note if I execute the same curl command on my Mac to upload to the SFTP site, I can readily unzip the artifact when I subsequently download it.
Any clues on why this happens, and how to fix it?

**Tags:** windows, curl

> **Comments:**
> **username_1**: Is there any chance the source path would differ on the build server? `./build_artifact.zip` for example, might the command be running from a different start folder, which means the relative path doesn't point to a file?  One quick check for this would be to look at the size of the file. If it's 0 bytes, you might be uploading "file not found", if that makes sense.  
> **username_0**: Thanks. It's the same file. I did check the file size and it's the same. On my scripts, I do a `dir(env.WORKSPACE) {}` before I execute the `curl` command, and the `WORKSPACE` is where the `build_artifact.zip` file is.  

---

## 2 answers

### Answer by username_0 on 2023-06-09. Score: -1 | Accepted answer

Updating to the latest Git bash, which included `curl v8.x` fixed the issue.


---

### Answer by username_2 on 2023-05-27. Score: 1

This could be the common known issue based on the upload transfer of binary files using the curl command on Windows.
By default, curl on a Windows device uses ASCII transfer mode which can cause issues with binary files like .zip archives. Whereas on a Mac device, the curl command uses binary transfer mode as default.
To avoid this, override the ASCII transfer method by implicitly specifying the  transfer mode as binary, by using the --ftp-binary option.
See amended command below:
$ curl -T ./build_artifact.zip -u 'user:password' ftp://ftp.company.com/devops/test/build_artifact.zip --ftp-ssl-reqd --ftp-create-dirs -k --ftp-binary

> **Comments:**
> **username_0**: I was hoping this would work. But I get `curl: option --ftp-binary is unknown`. Maybe later versions of `curl` have it, but apparently not `curl v7.x`.  

---

