The program didn't freeze, it just took a while with 14228 filespecs and 14229 files - it 6657 secs (nearly 111 minutes). All measurements were from calling "Extract" until received number of files - it probably took less time to extract the files! - Russell Peters ----- Original Message ----- From: "Russell Peters" <russellpeters@xxxxxxxxxxx> To: <delphizip@xxxxxxxxxxxxx> Sent: Saturday, March 16, 2002 3:42 PM Subject: [delphizip] Re: Problem when using large FSpecArgs counts > Just thought I'd check what you said - I zipped the Office97 art files (all > 14229 of them) > I found it took on my computer (800mhz celeron) 25 secs for 30 filespecs, 42 > secs for 50, 67 secs for 80, 385 secs for 457 (I am currently trying to > check with 14228 filespecs but it might have frozen - it's about an hour and > counting). > I think it might require some progress messages (not difficult to put in). > The match routine might be able to improved for when there are no wildcards > also (every file is matched with every filespec - no wonder it's time > consuming) > - Russell Peters > ----- Original Message ----- > From: "Angus Johnson" <ajohnson@xxxxxxxxxx> > To: <delphizip@xxxxxxxxxxxxx> > Sent: Thursday, March 14, 2002 11:52 AM > Subject: [delphizip] Problem when using large FSpecArgs counts > > > > Hello again to all. > > > > There seems to be a problem with the Unzdll.dll (with Ver160 at least) > when > > extracting large numbers of files (eg >1000) and when not using wildcard > > filespecs. > > > > I think this problem arises in the extract_or_test_files() function in > > Extract.c in the section headed: > > > > > /*-------------------------------------------------------------------------- > > - > > * RCV Added: Calculate number of files to process and the total file > > size. > > > > > *--------------------------------------------------------------------------- > > */ > > in the "while ( members_remaining )" loop. > > > > As the filespecs count increases, the time taken for this loop to complete > > increases exponentially, and any application will appear to "hang" till > this > > is completed. > > > > There must be a better way to handle this. As this loop is an addition to > > the original code, > > what functionality was missing before this? If it's mainly to check total > > file size prior to extraction, then I think, as a minimum, it would be a > > good idea to avoid this loop when extracting to non-removable media. (I > > would've liked to have spent more time thinking about these issues before > > raising the problem, but I currently have other things on my mind <sigh>.) > > > > On a related note - is there any plan to remove the limitations set by > > FileMax (max no. of files in a Zip file) which is currently 4096 (see > > Zcallbck.pas)? > > > > Angus > > > > > > > >