I’m having trouble with a curl command for uploading files to my Google Drive. When I upload an archive file, it goes through fine but the name doesn’t stick. Instead of the name I want, it just shows up as “Untitled” in my drive.
Here’s what I’m running:
curl -k -H "Authorization: Bearer `cat /tmp/access_token.txt`" -F "metadata={name : 'myarchive.zip'}" --data-binary "@myarchive.zip" https://www.googleapis.com/upload/drive/v2/files?uploadType=multipart
The upload works but the filename metadata seems to be ignored. What am I doing wrong with the naming part?
Your multipart structure is wrong. You need to properly separate the metadata and file data using multipart/related format. Try this:
curl -X POST \
-H "Authorization: Bearer $(cat /tmp/access_token.txt)" \
-H "Content-Type: multipart/related; boundary=boundary123" \
--data-binary @- \
https://www.googleapis.com/upload/drive/v2/files?uploadType=multipart << EOF
--boundary123
Content-Type: application/json
{"name": "myarchive.zip"}
--boundary123
Content-Type: application/zip
$(cat myarchive.zip)
--boundary123--
EOF
Or just use the simpler resumable upload method - separate metadata and file uploads. Drive API v2 gets finicky with multipart uploads when the boundary isn’t defined correctly.
Yeah, this is super common when you mix -F and --data-binary flags. They don’t play nice together - -F wants multipart/form-data while --data-binary sends raw data. I hit this exact issue last month automating Drive backups. Here’s what fixed it for me: ditch the multipart mess and use resumable uploads instead. Send a POST with just the metadata first, then PUT your file data to the upload URL it returns. Way more reliable than wrestling with multipart boundaries, especially for big archives. Also, v3 API handles this stuff much better if you can upgrade from v2.
hey, u gotta set the content-type propely. try adding -H "Content-Type: multipart/related" and fix the metadata format like this: "metadata={\"name\": \"myarchive.zip\"}"