I have the below error when launching TTsZipPackage 3.3.1 under Ubuntu 12.04 LTS Linux. If you click OK the app runs, but fails later when I go to unZip a file. I searched and found a ‘stat’ routine within the Zip libraries: dim stat as unix_stat_struct_linux
declare function stat lib SystemLib (path as CString, dataOut as Ptr) as Integer
static stat as new MemoryBlock(512)
Anyone know of a workaround?
[code]Runtime Error
Press OK to Continue
Press Cancel to Quit.
Please report what caused this error
along with the information below.
Common/Loaders/Loader.cpp: 176
Failure Condition: functionEntry
Could not resolve function ‘stat’ in libc.so[/code]
(Thanks for including me in this discussion. I had seen the post with the topic, but made no connection to my Zip classes, so I didn’t look into the conversation.)
Okay, so I screwed this up. I wrote and tested the TTsFolderItem.Exists function on OSX but not on Linux. On Linux, something like __lxstat should be used, see TTsFolderItem.update.
Or, if you know you won’t work add symlinks, simply remove the entire Exists function, because then RB’s FolderItem.Exists will be used (which has a problem with symlinks, see <https://xojo.com/issue/27683>)
Can you fix this yourself for now? I’ll see that I release a fix soon. After I’ve tested it properly.
Alright. v3.2.2 fixes the issue and also hopefully solves finding the libz file on Linux by using not a full path any more but just the complete name: “libz.so.1”.
It works now no longer gives the error on launching. When unzipping the below line has a problem, so I put it inside a try end try command and it works OK. Not sure the effect on Norton.
zdest.CreationDate = d // !TT 21Jun05 added to prevent Norton and other tools from complaining about creation > modification date
Norton? Bruhahaaa. That shows how old this code is. Norton Utils for Mac was a tool to check the integrity of HFS volumes. It would report warnings if the file’s modification date was before its creation date.
Now sure why you’d get an exception there, though. When I tried 3.3.2 on Windows and Linux, I saw no such exception, so I can’t tell what you’re seeing there.
Can you tell me what kind of exception it was? Was it a NilObjectExc, i.e. was zdest nil? No, that makes no sense, because the code makes sure that zdest is not nil earlier on. Odd.
Would be nice if you could double check that for me so that I can fix my code accordingly.
Oh, poop! It only happens in Xojo. I am still editing and testing in the old IDE because I find the new IDE still pretty unusable compared to the old one. Anyway.
And that’s just another example why the new IDE isn’t up to it yet: It does stop at an exception, shows me the line that you pointed out, and shows the little red “bug” icon. But it doesn’t tell me WHICH exception occured! Not even if I hover the mouse over it (in Xojo r1 this used to work still, at least). So I can’t even tell what the problem is. Sigh.
By adding a try/catch wrapper for “RuntimeException” I could figure out that it’s throwing an “UnsupportedOperationException”, with the message “Changing the creation date is not supported”. Good idea to have a function that used to set the ErrorCode property of the FolderItem for such errors before is now thowing an exception instead. Adds lots of surprises to old, well debugged code. Yay!
On the slightly bright side, the newer version of the IDE will have an ‘Exception’ variable in the variables pane that you can look at like a normal variable.
