UNZIP on VMS with a dowloaded CURL file

[robert70]

I have ran CURL on a PC to download a file called Y.ZIP - this file is then opened with WINZIP no problems - size of file 434,016 bytes

Same file downloaded via CURL on VMS arrives on the Alpha VMS 7.3-2 no problem (size of file is 4890/4992 blocks)
but when UNZIP.EXE is ran on this Y.ZIP I get the following error:-

DAVE$ unzip y

Error: zipfile is in variable-length record format. Please
run "bilf l DAVE$DKB1:[CURL]Y.ZIP;34" to convert the zipfile to stream-LF
record format. (BILF is available at various VMS archives.)

I have read other threads regarding doing the following to the ZIP file


$ CREATE STMLF.FDL
RECORD; FORMAT STREAM_LF
^Z
$ CONVERT/FDL=STMLF.FDL Y.ZIP X.ZIP

but still receive an unzip error as shown here:-

Archive: DAVE$DKB1:[CURL]X.ZIP;11
End-of-central-directory signature not found. Either this file is not
a zipfile, or it constitutes one disk of a multi-part archive. In the
latter case the central directory and zipfile comment will be found on
the last disk(s) of this archive.

any help please?

[robert70]

I have attached the file from the Alpha here if that helps?

[Brian Reiter]

Not as yet, though (assuming the zip file you've attached is the one you're struggling with) Powerarchiver 2001 doesn't like the file either, for that matter neither does 7-zip.

As expected, the OpenVMS spits it out too. Something wierd with Winzip perhaps? What creates the archive?

Can you FTP the archive from the Alpha to a PC and then still unzip it via Winzip?

Not a great deal of help I'm afraid.

cheers

Brian

[Hoff]

Please post...

...the curl command used

...the type of the target ftp (web) server

...the curl version.

...whether you're running with traditional or extended command parsing.

...the unzip version in use, and if you're not using unzip 6.0 here, please load and use that.

[robert70]

...the curl command used
the command is in a command file y.com

curl "-v" "-k" "-x" proxy.kk.kkkk.kkkk:8080 "-U" user:password
"-F" username=user "-F" password=password
"-F" date=20091104 "-F"
format=xml "-F" report=COMPOSITES_BY_CONVENTION "-F" version=5 "-F"
type=CDS https://www.webiste.com/export.jsp

and at the dollar prompt we do
$ @y /out=y.zip
---------------------------------------------
...the type of the target ftp (web) server
? not sure what you mean here sorry
---------------------------------------------
...the curl version.
curl 7.19.5 (ALPHA-HP-VMS) libcurl/7.19.5 OpenSSL/0.9.7e
---------------------------------------------
...whether you're running with traditional or extended command parsing.
? again not sure what you mean here sorry
---------------------------------------------
...the unzip version in use, and if you're not using unzip 6.0 here, please load and use that.
using version UnZip 5.52
Will download 6.0 now online - if i can find it.

Thanks

[Steven Schweda]

What's wrong with this picture?

> size of file 434,016 bytes

> (size of file is 4890/4992 blocks)

Unless your blocks are bigger than my
blocks, this must be some new meaning of "no
problem".

> Error: zipfile is in variable-length record format. Please
> run "bilf l DAVE$DKB1:[CURL]Y.ZIP;34" [...]

http://forums.itrc.hp.com/service/forums/questionanswer.do?threadId=1382921

> Nov 4, 2009 14:14:14 GMT 2 pts

Going from ";22" to ";34" suggests that you
didn't pay any attention to some previous
advice.

> close this - opening new thread re the
> unzip problem

Because you think that these problems are
unrelated?

> End-of-central-directory signature not found.

This is typical for a corrupted and/or
truncated archive. With both a bad size and
bad attributes, I can only guess which
problem is bigger.

> ...the unzip version in use,

Always good advice.

> and if you're not using unzip 6.0 here,
> please load and use that.

Also reasonable, but it probably won't help
here.

[Steven Schweda]

> ...whether you're running with traditional
> or extended command parsing.
> ? again not sure what you mean here sorry

HELP SET PROCESS /PARSE_STYLE

SHOW PROCESS /PARSE_STYLE

[robert70]

Im using traditional parse style

I have deleted all previous versions of y.zip
but still the same problems

[Hoff · Accepted solution]

You're accustomed to Unix and Unix shell scripting, eh? Mapping that knowledge over tends to have issues with DCL.

Here's what looks to be your bug:

$ @y /out=y.zip

That creates a VFC sequential file, and not the file that zip expects.

Ask cURL to dump the contents to a file, or use COPY /FTP or such at DCL and skip cURL here.

And FWIW, sftp doesn't expose your authentication credentials in cleartext and allows for certificate-based no-password logins and for certificate revocations, but I think we've already had that discussion.

> ...the type of the target ftp (web) server
> ? not sure what you mean here sorry

I mean: what remote ftp or web server are you accessing?

Given the use of the @ command to aim the output, it's less likely that the remote server is the issue.

I ask this identity because some servers can adjust whether the download is binary or ASCII, either implicitly or (with the data type tag) explicitly. And some clients can and do adapt to the target server, and this can alter the behavior of the client transfers.

Microsoft clients are notable here for instance, as they can punt when presented with an OpenVMS ftp server (and where I usually recommend FileZilla on Windows, which has a GUI and is known to operate with OpenVMS ftp servers), and where OpenVMS ftp servers can send over directory listings with filespecs that they then can't resolve correctly on a subsequent GET.

This stuff gets hairy, so knowing what you're dealing with (on both ends of a network connection) can be helpful.

And if the remote server is running FTP for this transfer, then using the command COPY /FTP is easier.

>...whether you're running with traditional or extended command parsing.
>? again not sure what you mean here sorry

See the SET PROCESS /PARSE command documentation, and related. This command alters how commands are input, and particularly how foreign commands (which is what cURL usually is) operate.


>...the unzip version in use, and if you're not using unzip 6.0 here, please load and use that.
>using version UnZip 5.52
>Will download 6.0 now online - if i can find it.

DIRECTORY /FTP /ANONYMOUS ftp.process.com::

Work your way down through the Freeware and FILESERV directory stuff, then:

COPY /FTP /BINARY /ANON the UNZIP.ZIP file over.

Then unpack it with your unzip tool.

Then set default into the [UNZIP60.VMS-BINARIES] subdirectory

Then invoke LINK.COM

Then transfer the UNZIP.*EXE* tool to your tools area, or aim your unzip symbol at it.

[robert70]

Hoff,
You are right more used to UNIX!

but you are correct when using the "--output filename" flag the file comes across correctly. It recognises the zip file as a good zip but when i unzip the name of one of the files is too long? im getting this....

DAVE$ unzip y
Archive: DAVE$DKB1:[CURL]Y.ZIP;1
[ Cannot create output file V5_CDS_Composites_by_Convention1257424176127
.xml ]
[ %RMS-E-CRE, ACP file create failed ]
[ %SYSTEM-W-BADFILENAME, bad file name syntax ]

any ideas on this?
thank you all for ur help

[robert70]

this is now working
using an uptodate version of unzip solves the name convention problem
cheers again all