GMan's Zip module issue - poss file size?
BlitzMax Forums/BlitzMax Programming/GMan's Zip module issue - poss file size?
| ||
| I'm getting an unhandled exception on ZipReader.ExtractFileToDisk but the file is in the zip. This only happens on some zips so not sure why its failing. I'm wondering if it is a size limit problem (one of the files is 4.5MB - not massive but this is the only real difference I can see). Does anyone know what the max file size is for files being written/extracted with this mod? |
| ||
| Maybe you should try to do it in a debug-build. bye Ron |
| ||
| I used 7zip commandline version for my backup program as it seemed more stable and no filesize limits. With Gman's mod it gave me an exception somewhere around 600 megs. But this was long time ago. -Henri |
| ||
| I did do a debug build, that's how I know it errored on ExtractFileToDisk - but I don't have time to debug the mod, esp if its just a limitation of it. I'm nowhere near 600 MB but might be worth just trying 7zip and see if that works. Edit: Is this the correct Blitz code for 7zip? http://www.blitzbasic.com/codearcs/codearcs.php?code=2377 Ideally I'd like to continue with Gman's mod as its gonna be a lot of work to replace it in my code (its a very complex app) |
| ||
| As it's command line app you could use pub.Freeprocess to execute it or ShellExecute if only for Windows. -Henri |
| ||
| Ah right, thanks. |
| ||
| Another alternative may be Koriolis' zipstream module |
| ||
| Just run your app and see at which code line it crashes in extractFileToDisk. Think when relying on 3rd party code in your app that time should be worth to get spend. bye Ron |
| ||
| GMan has a forum here: http://www.gprogs.com/viewforum.php?id=8 It might be worth dropping a line there. |
| ||
| Tried forum but register link just goes to a blank page so can't post there. Might have a crack at fixing the bug in GMan's code, but will prob have to resort to another zip module. If GMan happens to see this post, this is my code: Local zrObject:ZipReader = New ZipReader If zrObject.OpenZip(currentProject$) Then zrObject.ExtractFileToDisk(projectXmlFile$, tempPath$ + projectXmlFile$) '<-- error here zrObject.CloseZip() End If The error is 'Unhandled Exception: Attempt to access field or method of Null object.', and the debugger shows that in the getFileInfoByName function, m_zipFileList:TZipFileList = Null (which I am assuming is the cause of the error as its the only Null field I can see) |
| ||
| Think that portion of code wont help that much. When the debugger stops in (your programme crashes) you have seen that "m_zipFileList" is null. So this object isnt filled/created correctly. Means you now go back in history (on the right sided pane with the debug entries just move up and up and up...) until you reach the step which should create/pass/... m_zipFileList. Then check why it might not get created correctly. bye Ron |
| ||
| I know how to debug a program :p I just don't want to waste time debugging someone else's code that might ultimately prove useless anyway. I was just giving some info to point GMan in the right direction should he read this thread. |
| ||
| OK, I've fixed the errors in GMan's code. I searched zipengine.bmx for all 'm_zipFileList.' and made sure they were preceded by 'If m_zipFileList Then ', and ditto for 'info.' preceded by 'If info Then ' - this has made it more robust and prevents the unhandled exceptions. It looks like those fields are null due to getting lots of 'I/O error : Too many open files'. Still investigating the cause of I/O errors - looks like its when I'm parsing the XML files (using libxml) extracted from the zip. |
| ||
| your "ifs" just secure it against crashing - but like you already described there seems to be another issue around. Do you happen to be able to reproduce that I/O-error without the zip functionality? (just handling some hundred of xmls or so). bye Ron |
| ||
| Indeed, but better to have robust code so it doesn't crash and/or give misleading errors (which is what was happening). The I/O error seems to be a libxml one, and I'm fairly certain it is causing the zip failure - zip is fine until xml is used. I thought it might be a file/node limit of the xml mod, but that doesn't seem to be the case. I'll write some code to try test libxml independently of the zip stuff to hopefully find out one way or the other. |
| ||
| Finally found the problem. I was inadvertently loading a LOT of image fonts - this caused the too many open files error, which was also causing the zip to fail. Phew, problem solved. |
| ||
| That is why I pushed you to debug the problem :D @open files error is it just not returning valid handles - or does it raise a real error message? bye Ron |
| ||
| After fixing the zip mod, the only errors it gave were the 'too many open files' ones which I'm sure are from libxml, and occasionally a similar one stating it couldn't open the xml file. These were not runtime errors that ended execution (would have been a lot easier to find the prob if they did), but were only shown in the output window AFTER closing the app. |
   |