Updating the test program to show the results of forcing fopen to be:

~~~~~
   file = fopen(argv[1], "r", "rfm = stmlf", "ctx = stm");
~~~~~

Results in the STM_LF and the FIXED record cases to now read the files as expected. STM_CR should also work, but the resulting file will have \r as the record delimiter instead of \n, and when the file is read back on VMS, it will be created as a STM_LF file, so will become unreadable.

The above results in an exact binary copy of the file in all cases, but the VMS specific record attributes are lost, making the file unusable on VMS except for the STM_LF case. For the FIXED size, it is usually not too hard to repair the attributes.

So for STM_CR the fopen below works in a DO WHAT I MEAN mode as below, with out the "b" to allow the record translation.

~~~~~
   file = fopen(argv[1], "r");
~~~~~

It does not work for the variable file organizations used for text files, we need the fopen above, but need to read the files that way once to get their correct size instead of relying on stat st_size.

This then brings up a limitation of fread on VMS. fread on VMS will read in a maxium of 65536 bytes or the size of a record for the above fopen call. For "ctx=stm", only the 65536 limit applies.

On VMS, multiple fread calls are needed in a loop to get around this limitation to attempt to read the desired amount of data.

---
** [bugs:#758] VMS-Alpha, http-upload not working**
**Status:** open-confirmed
**Labels:** http VMS 
**Created:** Mon Aug 18, 2008 04:09 PM UTC by Harald Schwarz
**Last Updated:** Fri Jul 19, 2013 04:35 AM 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.