When receiving multiple binary files from Array_Binfile, file data errors may occur. #187
Description
I made a program wanna use form-data to post multiple file to server, and check the files hashes. Then I found that, some files data has errors, only latest file is correct.
This is my curl command, the first file is i really wanna stay at your house.m4a, file size is 3007845 bytes, the second file is All in one - v17 (1.14.74.0) Address Library-3256-17-1732048336.zip, file size is 20506623 bytes, the hash values of these two files, as calculated on the server, are as follows: AD7975D42... and 473425015.... and the first file(the m4a file) is broken, i open it with hex editor, i found the front bytes are 50 4B(PK), it's like a zip file not a m4a file.
curl -X 'POST' \
'http://localhost:3000/api/paste' \
-H 'accept: application/json' \
-H 'Content-Type: multipart/form-data' \
-F 'paste={"content":"work! "}' \
-F 'file=@i really wanna stay at your house.m4a;type=audio/mp4' \
-F 'file=@All in one - v17 (1.14.74.0) Address Library-3256-17-1732048336.zip;type=application/zip'And i try send one file only, just send the music file (mp4 file), then got file size is 3007845 bytes, hash is 7A68DC8991..., is different with first time i send.
When i try to send the two file both again, and the got the info as same as the first time.
I modified example code and want to figure out where is the issue, and i found that it's has same problem.
For test, i made 4 files:
dd if=/dev/urandom of=test_file_1 bs=1M count=2
dd if=/dev/urandom of=test_file_2 bs=1M count=2
echo hello >> test_file_3
echo hello2 >> test_file_4
curl -v --request POST -F img=@test_file_1 http://127.0.0.1:3000
curl -v --request POST -F img=@test_file_2 http://127.0.0.1:3000
curl -v --request POST -F img=@test_file_1 -F img=@test_file_2 http://127.0.0.1:3000
curl -v --request POST -F img=@test_file_3 -F img=@test_file_4 http://127.0.0.1:3000and when send test_file_1 and test_file_2 both, one of them will broken. but when send test_file_3 and test_file_4, all files are good.
zap logs
127.0.0.1 - - [Tue, 30 Dec 2025 11:46:42 GMT] "POST / HTTP/1.1" 200 14b 1350us 127.0.0.1 - - [Tue, 30 Dec 2025 12:01:14 GMT] "POST /api/paste HTTP/1.1" 413 17b 526us info: Body length is 2097366 info: param_count: 1debug: filename:
test_file_2
debug: mimetype: application/octet-stream
debug: hash: 548BA5F790D90CFA90A80CB989BA55F6D42D1814F61A3507FC828A5A52652A034C2B4AEF8E3D776E0F420233F428382227B1A3E0D9F6A5D877D6F1C46850824D
debug(zap): setting content-type to application/json
127.0.0.1 - - [Tue, 30 Dec 2025 12:19:17 GMT] "POST / HTTP/1.1" 200 14b 1098348us
info: Body length is 2097364
info: param_count: 1debug: filename:
test_file
debug: mimetype: application/octet-stream
debug: hash: 64240E11F1B3EC2226F5B855FA52AEDFA4694153BBAAB2EF7FDCBAC65B3FDB6EEEAC963939C6F8F3E2A12AA4AD1A82788DB11B50AA959B5BB5FBCCE2A349C7B7
debug(zap): setting content-type to application/json
127.0.0.1 - - [Tue, 30 Dec 2025 12:19:26 GMT] "POST / HTTP/1.1" 200 14b 1086365us
info: Body length is 4194679
info: param_count: 2debug: filename:
test_file
debug: mimetype: application/octet-stream
debug: hash: 548BA5F790D90CFA90A80CB989BA55F6D42D1814F61A3507FC828A5A52652A034C2B4AEF8E3D776E0F420233F428382227B1A3E0D9F6A5D877D6F1C46850824D
debug: filename:test_file_2
debug: mimetype: application/octet-stream
debug: hash: 548BA5F790D90CFA90A80CB989BA55F6D42D1814F61A3507FC828A5A52652A034C2B4AEF8E3D776E0F420233F428382227B1A3E0D9F6A5D877D6F1C46850824D
debug(zap): setting content-type to application/json
127.0.0.1 - - [Tue, 30 Dec 2025 12:19:39 GMT] "POST / HTTP/1.1" 200 14b 1167782us
Edit
I am using zap version is: git+https://github.com/zigzap/zap?ref=v0.11.0#66c5dc42c781bbb8a9100afda3c7e69ee96eddf3
And i found the reason, this file_data.data seem like a buffer, the data will be overwrite at next loop.
Lines 215 to 222 in 76679f3
I add my test code below and the hash is be normal:
zap logs
Terminate with CTRL+C or by sending query param terminate=true info: Body length is 4194678 info: param_count: 1 test_file: 64240E11F1B3EC2226F5B855FA52AEDFA4694153BBAAB2EF7FDCBAC65B3FDB6EEEAC963939C6F8F3E2A12AA4AD1A82788DB11B50AA959B5BB5FBCCE2A349C7B7 test_file_2: 548BA5F790D90CFA90A80CB989BA55F6D42D1814F61A3507FC828A5A52652A034C2B4AEF8E3D776E0F420233F428382227B1A3E0D9F6A5D877D6F1C46850824D
debug: filename:test_file
debug: mimetype: application/octet-stream
debug: hash: 548BA5F790D90CFA90A80CB989BA55F6D42D1814F61A3507FC828A5A52652A034C2B4AEF8E3D776E0F420233F428382227B1A3E0D9F6A5D877D6F1C46850824D
debug: filename:test_file_2
debug: mimetype: application/octet-stream
debug: hash: 548BA5F790D90CFA90A80CB989BA55F6D42D1814F61A3507FC828A5A52652A034C2B4AEF8E3D776E0F420233F428382227B1A3E0D9F6A5D877D6F1C46850824D
debug(zap): setting content-type to application/json
127.0.0.1 - - [Tue, 30 Dec 2025 13:12:22 GMT] "POST / HTTP/1.1" 200 14b 1048150us
Edit
Seems the data has be overwrite at callback step:
Line 772 in 76679f3
emm... I wish there was a way to control the where loop within method parseBinfilesFrom method, there is a simple way to fix it is dupu data as a copy, but i don't wanna that....
I spent some time trying to find a solution to this problem. I figured it out: the data was being overwritten every time the Context.callback function was called and during the BinfileArray loop. Therefore, the problem can be avoided by retrieving only one Binfile at a time. So I copied some the zap find Binfile code and write a new Context.callback method to avoid data been overwritten: https://github.com/SmileYik/zapaste/blob/master/src/common/zap_params_finder.zig