I found the stat() call in this case from the AddFormData case.

The stat structure from VMS has some additional fields. The fields that are of most interest in this case are:

~~~~~
   st_fab_rfm: Record format - see fabdef.h fragment below.
   st_fab_rat: Record attributes.

From <fabdef.h>
#define FAB$C_UDF 0 /* undefined (also stream binary) */
#define FAB$C_FIX 1 /* fixed length records */
#define FAB$C_VAR 2 /* variable length records */
#define FAB$C_VFC 3 /* variable fixed control */
#define FAB$C_STM 4 /* RMS-11 stream (valid only for sequen♦
#define FAB$C_STMLF 5 /* LF stream (valid only for sequential♦
#define FAB$C_STMCR 6 /* CR stream (valid only for sequential♦
~~~~~

So basically if st_fab_rfm is one of 0, 5, 6, the st_stat size can be used.

For the other values, st_stat size can not be trusted for most file type that would be uploaded, it will be larger than the actual size.

While FAB$C_FIX might seem safe, it is not because the st_size is apparently rounded up to whole blocks and not adjusted for any partial block at the end.

The only way to get the exact size as seen from a C program is to read in the files. For a quick fix, that would be to read in the file, discarding the data. While it would seem wasteful, it would actually warm the caches used in the read operation that is going to follow.

So would you prefer a wrapper to stat() or something like:

~~~~~
curl_off_t get_vms_file_size(file) {
    /* Read and discard the data */
}

....


#ifdef __VMS

    switch(stat.st_fab_rfm)
    {
        case 0, 5, 6:
              break;
        default:
              *size += get_vms_file_size()
    }
#endif
~~~~~

Now I saw fstat() calls in a few other modules, so is similar treatment needed form them?


The implications of this work around also need to be added to the VMS readme. file.

---
** [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:** Mon Jul 15, 2013 12:44 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.