This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Problem to open big selfextracting Zip files from bash -- Back to the problem -- Multiple Environment discussion


Hey guys

Can we have one of the cygwin developers trying to reproduce our issue.
The -- Multiple Environment discussion part of this thread seems to went
a little bit of topic from the root cause of the real problem.

Hoping for your guys understanding that we don't want to raise some
kind of conflicts with our request and the answers to it.
We are just seeking for help ;-)

Regards Dirk

Hi Barry

Hmmm... That says corruption ISN'T to blame, and that either unzip or the latest cygwin are to blame.
Our guess is the latest cygwin. Both versions have been tested on
Win2000 & XP acting in the same
way. The old one works, the new one doesn't.

If the SFX block is Windows XP (or Vista) SFX, I can see that Cygwin might get confused trying to run an XP/Vista SFX since Cygwin doesn't play well
with Vista, from what I've read.
It is just about to get it to work on Win2000 and XP. Vista is not in
the game.

I also looked at the online Cygwin User Guide, and ran across an interesting

tidbit that would definitely impact a large SFX detailed in the article "Changing Cygwin's Maximum Memory".
"By default no Cygwin program can allocate more than 384 MB of memory (program+data)."
Unless you've taken the steps in your "new" cygwin to expand the ammount of memory that Cygwin can allocate, I would think that you might be running out
of memory.
We did not manually changed Cygwin's Maximum Memory in both version.
Cygwin installation is
a out of the box install by default. If "Changing Cygwin's Maximum
Memory" would be the solution.
why are than SFX files above 384 MB are not an issue as well.
We found 1GB files working well while 1.5GB once failed.
A purchased application? Not Zip or Cygwin?
Sounds like you should contact the support for this other application,
or start an in-house project to write a replacement for "the code we cannot change". If you are talking about applications that you have lost the source for, then this is a PERFECT time to rewrite the application
that is not able to execute the SFX correctly.


Sorry. I'm a programmer. There is always a way to write an application that will work in the "new" circumstances, that will give you source that you have more control over, and will perform the task that you need for the source and the application to do. Having control over the source will make your company money in the long-term.

From the programmer point of view you are absolutely right :-)
But there are always politic circumstances in huge companys ;-)

So, now I'm confused. Is this a problem with Cygwin or Windows?

We believe it is cygwin related due to the fact that the old one work while the new one doesn't I would be great if someone of the cygwin developers can give it a try as well to confirm this issue and finally help to resolve it. This is why we placed it to this mailing list :-)

Looking forward to some more reply on this.

Best Regards Dirk




Barry Smith at SourceLink schrieb:
Hi, Dirk.

Just saw this response, and finally synced on the relevant part of the response
We are using the same zip file on both versions of cygwin.
./ execution works in the old one without issues, but not in the latest.
Hmmm... That says corruption ISN'T to blame, and that either unzip or the latest cygwin are to blame.

Since Self-Extracting zips are just ZIP files with an extraction program prepended on the front of the file -- the only "corruption/non-execution" issue that comes to mind is Windows SFX vs Cygwin SFX.

If the SFX block is Windows XP (or Vista) SFX, I can see that Cygwin might get confused trying to run an XP/Vista SFX since Cygwin doesn't play well
with Vista, from what I've read.


I just read a thread where Cyg-X RUN.EXE would cause a blue screen crash,
yet a Windows START command would run the program under Windows, and therefore the program would run correctly. There wasn't any information
about executing a START from a cygwin script.


I also looked at the online Cygwin User Guide, and ran across an interesting

tidbit that would definitely impact a large SFX detailed in the article "Changing Cygwin's Maximum Memory".
"By default no Cygwin program can allocate more than 384 MB of memory (program+data)."
Unless you've taken the steps in your "new" cygwin to expand the ammount of memory that Cygwin can allocate, I would think that you might be running out
of memory.


The problem is that we are not able to change the way the zipfiles is called, because this is part of some other code we can not change.

A purchased application? Not Zip or Cygwin?
Sounds like you should contact the support for this other application,
or start an in-house project to write a replacement for "the code we cannot change". If you are talking about applications that you have lost the source for, then this is a PERFECT time to rewrite the application
that is not able to execute the SFX correctly.


And in addition other exe files are also called via that code without checking if it is a zipfile that can be opened via a workaround.
Or in other words it have to work with ./ execution. No way for a workaround like unzip recreating the zipfile with spanning method.
Sorry. I'm a programmer. There is always a way to write an application that will work in the "new" circumstances, that will give you source that you have more control over, and will perform the task that you need for the source and the application to do. Having control over the source will make your company money in the long-term.

So, now I'm confused. Is this a problem with Cygwin or Windows?

Best of luck in finding a solution,

Barry Smith
-----Original Message-----
From: Dirk Napierala [mailto:Dirk.Napierala@oracle.com] Sent: Monday, September 22, 2008 3:17 AM
To: Barry Smith at SourceLink
Subject: Re: Problem to open big selfextracting Zip files from bash


Hi Barry,

First thanks for your feedback.
But the issue is not related to zip corruption.

We are using the same zip file on both versions of cygwin.
./ execution works in the old one without issues, but not in the latest.

The problem is that we are not able to change the way the zipfiles is
called, because this is part of some other code we can not change.
And in addition other exe files are also called via that code without
checking if it is a zipfile that can be opend via a workaround.
Or in other words it have to work with ./ execution. No way for a workaround
like unzip recreating the zipfile with spanning method.

Regards Dirk


Barry Smith at SourceLink schrieb:
Dirk --

Fortunately, the issue with zip corruption (in dealing with files over 1
gig) is documented
fairly well in multiple web locations with test results. I don't know the code for Zip, so
I can't speak to where in the source the corruption occurs. RAR and
WinRAR
(other compression
tools based upon Tar, the TRUE standard in "tape archiving") both completely support the ZIP spec, but I think I read that large Zips created with *RAR also become corrupt. The point that I'm trying to make is. "It's not the Zip tool, it's the Zip spec."


Personally, both for personal AND business use, I switched over to RAR (and
WinRar) exclusively
over three years ago.


RAR (and WinRAR) both create self-extracting archives.

Also, what Zip calls "spanning" (or compressing to multiple volumes) is perfectly supported in Rar.

If you don't want to give up the Zip ghost (and presuming that the SE-Zip can be re-created from the original files), try zip-spanning. If I remember correctly, the first file will be an exe, and the next parts will be zip files.

Best of luck.

Barry Smith
-----Original Message-----
From: cygwin-owner@cygwin.com [mailto:cygwin-owner@cygwin.com] On Behalf Of Dirk Napierala
Sent: Friday, September 19, 2008 9:59 AM
To: cygwin@cygwin.com
Cc: EVERS,DIRK; ZELL,VOLKER
Subject: Problem to open big selfextracting Zip files from bash


Hi there,

We discovered an issue  trying to open big selfextracting zip files.
Trying to do so result in the following error:

./*selfextracting_zipfile*.exe
bash: ./*selfextracting_zipfile*.exe: Cannot allocate memory

This only happens to huge files (guess above 1.5GB size) Smaller once are working fine.

This issue happens on the current version available for download 1.5.25-15 and also with the new 1.7.0 (base-files version 3.7-1)(thanks to Volker Zell providing us this one for testing)

If we are using an older version instead (1.5.18 base-files version
3.6-1) this issue doesn't show up.
We tried the same selfextracting zip file on each of the above mentioned versions on a Dell Optiplex GX280 with 2GB memory.


After discussing this issue with Volker Zell he mentioned to send this incident to your mailing list.
Hopefully someone can assist us with that and provide a fix.


Best Regard Dirk Napierala



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/




--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]