I just was made aware of this bug.

On VMS, the size returned from the fstat() call is the size of the file on the disk, not the size of the file being read.

In order to get the exact size of the file for all VMS file formats, it must be read() in until the end of file.

A search of the code reveals the only call to fstat() that is likely used for a file transfer is in lib/file.c routine file_upload().

The problem here seems to be that the information from fstat() is being used for the content-length field and is sent to the server before the entire file is read() and we know the true file size on VMS.

Now we can easily look at some VMS specific fields in structure returned by fstat() on VMS and detect the conditions when the st_size may not be correct.

And that leaves us with what to do when it may not. What we have to do is read the entire file to get the actual size. The quick and dirty solution is to simply read the file and toss the data away in a wrapper to stat().

Otherwise we have to buffer the data for the file somewhere and so that the later read() can pull it in.

There is a similar issue in gnu tar that if it is used to create a tar archive with a VMS binary file, the resulting archive will be corrupted and unreadable.

Only the CPAN Perl Tar module has the correct code to save VMS binary files.

---
** [bugs:#758] VMS-Alpha, http-upload not working**
**Status:** closed-later
**Labels:** http 
**Created:** Mon Aug 18, 2008 04:09 PM UTC by Harald Schwarz
**Last Updated:** Fri Jun 21, 2013 01:43 PM UTC
**Owner:** Daniel Stenberg
On VMS-Alpha: 
When using an http-file-upload the file is not sent to the Server with the correct content-length. 
Sending a file with 511 or less bytes, content-length 512 is used. 
Sending a file with 513 - 1023 bytes, content-length 1024 is used. 
Files with a length of a multiple of 512 Bytes show the correct content-length. Only these files work for upload.
Test-Commands on VMS-Alpha, Linux \(Suse\) and Windows: 
curl --form myfile=@test.ras --trace-ascii testras.log http://my\_web\_test\_server/cgi-bin/upload.pl 
curl --form myfile=@test.doc --trace-ascii testdoc.log http://my\_web\_test\_server/cgi-bin/upload.pl
File test.doc has the size 21.504 \(multiple of 512\) 
File test.ras has the size  5.686 \(not a multiple of 512\).
Using test.doc everything works. 
Using test.ras the Content-Length in the LOG-File differs from the content length on Linux/Windows. 
The receiving program \(in my testcase "upload.pl"\) says that I have a post-data mismatch.
VMS shows: 
002c: Content-Disposition: form-data; name="myfile"; filename="test.ra 
006c: s" 
0070: Content-Type: application/octet-stream 
0098: 
=> Send data, 6144 bytes \(0x1800\)
Linux + Windows show: 
002c: Content-Disposition: form-data; name="myfile"; filename="test.ra 
006c: s" 
0070: Content-Type: application/octet-stream 
0098: 
=> Send data, 5686 bytes \(0x1636\)
My workaround: I wrote a perl-program to add some bytes to the file to have a multiple of 512 Bytes. The CGI-Program \(upload.pl\) then reduces the filesize back to the origin.
This workaround works for all files with all sizes - but the error in curl still remains. 
Now I have to say, that I'm not a C-Programmer, so I kindly ask for help.
If you need a VMS-Alpha for testing \(incl. Compiler, ...\), please have a look at www.polarhome.com. 
On VMS-Alpha: before you can use "curl" as a program you have to define a symbol that points to CURL.EXE. 
curl = "$...\[...\]CURL.EXE" 
Then "curl" can be startet as described above.
Used CURL-Version on all systems: 7.18.2.
---
Sent from sourceforge.net because curl-tracker@cool.haxx.se is subscribed to https://sourceforge.net/p/curl/bugs/
To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/curl/admin/bugs/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.