Mail Archives: cygwin/2008/09/23/03:58:10
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 DOT Napierala AT oracle DOT 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 AT cygwin DOT com [mailto:cygwin-owner AT cygwin DOT com] On
>> Behalf Of Dirk Napierala
>> Sent: Friday, September 19, 2008 9:59 AM
>> To: cygwin AT cygwin DOT 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/
- Raw text -