ZIP UDF (zipfldr.dll library)

[wraithdu]

http://en.wikipedia.org/wiki/Zip_(file_format)#Limits

http://msdn.microsoft.com/en-us/library/aa384187(v=vs.85).aspx

[poorman]

http://en.wikipedia.org/wiki/Zip_(file_format)#Limits http://msdn.microsoft.com/en-us/library/aa384187(v=vs.85).aspx

Many thanks for the reply! It is surely appreciated. After reviewing the material it looks like if I could get to the 64 bit version of the zipfldr.dll I should be able to put all the files in the folder previously mentioned (25) 2 gig files in one zip. So I'm guessing that I would need to compile the script on a 64 bit machine to make this work. I'll get access to one later today or tomorrow (the boss don't want it on the server) and update this thread with the progress either way.

[poorman]

So the results are a little disappointing. I compiled the script on a 64 bit system and I get the same results. I see the @SystemDir is still c:windowsSysWOW64. Would it be true if I change the line (787) in _Zip.au3 in the _Zip_DllChk() that contains @SystemDir & "zipfldr.dll" to "C:\Windows\System32\zipfldr.dll" would this force the script to use the 64 bit version? Or can I make some other modification to force the use of the 64 bit version, such as what I found in the help file but I'm unclear where to put it. I think I should just make this one of the first lines in MY script. So I tried that AND it still fails at 8 gig with the message saying the file is corrupt. Any further help is appreciated!

<FROM HELP FILE> It is possible to access the 64-bit version of those directories by disabling the redirection mechanism.

DllCall("kernel32.dll", "int", "Wow64DisableWow64FsRedirection", "int", 1)

</FROM HELP FILE>

[wraithdu]

You did not read carefully enough. zip64 is a new zip file specification, not the 64-bit version of the zipfldr library. zipfldr plainly does not support the zip64 format (at least for creating zip files, you may be able to open a zip64 file on Vista+). Only some 3rd part zip applications like WinZip support creating such files.

[poorman]

Thanks Wraithdu! I sure did miss that. Confusing to me but I certainly appreciate your reply. I'm gonna try 7-zip.

[emendelson]

This is a superb UDF, which makes it easy for me to write scripts that wouldn't have worked without them.

One question or problem:

I use _Zip_UnzipAll to extract the contents of a zip file to a folder. The zip contains a folder named "gs" with dozens of files in it. When I use _Zip_UnzipAll to extract it to C:MyFolder, and C:MyFolder already contains a folder named "gs", then Windows pops up a "Confirm Folder Replace" dialog, with Yes, Yes to All, etc. - and the function does not click "Yes to all" even though I have the flag set to 20 or 16 in the function call. (16 is supposed to click Yes to All.)

Does this feature work only when replacing files, not with "Confirm Folder Replace" or am I doing something wrong?

[Enigma]

Today is my weirdness day. :-) I'm using the _Zip.au3 file and I am getting the error "Zip File Does not exist". I copied the error messages from the doc in the include file and even traced the problem back to the _Zip_GetNameSpace() function where it does the:

Local $oNS = $oApp.NameSpace($sZipFile)

...line. The first image is the directory where the zip files are located. The second is a MsgBox I put just inside of the _Zip_UnzipAll() function and the third is the second MsgBox to tell me the Destination folder. Ideas on why this is not working? The spaces maybe? I've tried moving the zip files to just "c:/Dotcodes.zip" and have gotten the same error. So I am discounting spaces as the cause. But what can I say? Any ideas would be greatly appreciated. :-)

Sorry - my mistake - if I move Dotcodes.zip to "c:/Dotcodes.zip" I get the error "Not a full path" and not the "Zip file does not exist" error. So error code #3. :-/

Update: If I move the files to c:TEMP then the _Zip routines work as expected. I can live with that. :-) So the above problems are problems - but there is a work-around.

Thanks for taking on this project! I REALLY DO APPREICATE IT! When I get paid I can make a small donation from what I am being paid. The rest goes to pay taxes. :-/ What can I say? It's that time of year. :-P

Edited March 12, 2012 by Enigma

[wraithdu]

Without any AutoIt code I can't guess at your problem really, but make sure you are using FULL paths to refer to the zip files, no matter where they are located.

[Enigma]

Ummmmm....er.......ok.

Let me step you through this. The smallest amount of code I can give you is I call the _Zip_UnzipAll function and pass in the two paths given on images #2 and #3. so it would be:

_Zip_UnzipAll( "C:Documents and SettingsMarkApplication DataWinDotupdatesDotcodes.zip", "C:Documents and SettingsMarkApplication DataWinDotarchives" );

That command, by itself, caused the error found in image #4.

Image #1 shows the directory where the zip files are located. The program resides in a different directory.

For the second error you would need:

_Zip_UnzipAll( "C:Dotcodes.zip", "C:Documents and SettingsMarkApplication DataWinDotarchives" );

which gave error #3.

If I put the Dotcodes.zip file into the C:TEMP folder and then call:

_Zip_UnzipAll( "C:TEMPDotcodes.zip", "C:Documents and SettingsMarkApplication DataWinDotarchives" );

It all works just fine. :-)

A bit obvious - the code I mean - wouldn't you say? :-)

And yes - I did make a test.php file with just those one line commands in them. :-)

Since the C:TEMP seems to work - this is now more of a "I believe you have an error in the code somewhere." Since I traced it down to the NameSpace(...) part I'm not even sure if it would be a part of your program. This is like the _FTP_ListToArrayEx() function problem. Turned out to be an error in the package and someone said "That sounds like this error (Bug #1970 btw)." Which is what it turned out to be. But that one I also traced to a NameSpace command. However, the actual error was somewhere else. :-/ Oh well. What can I say? Didn't write the function. :-) Just trying to see if I can give whoever is working on the function a bit of information so maybe they can figure it out. :-)

I thought I'd add: I tried running the above code via the right-click->Run Script and just typing out "autoit3 test.php".

Edited March 12, 2012 by Enigma

[wraithdu]

Wait, where does PHP fit in to all this? Could this be a permissions problem with some external process not having user rights to your profile or C: root directories?

Another note... I hate the zipfldr library and I hate this UDF to be honest I highly recommend you look into some of the 7-zip UDFs.

Edited March 12, 2012 by wraithdu

[Enigma]

Sorry - I meant test.au3. I do PHP coding during the day and am a secret AutoIt writer at night. (Sort of like Batman. :-) ) So I wrote test.php instead of test.au3 by accident. :-)

7-zip will handle Zip files? I'll go look at it. :-) Thanks!

I don't think you should hate it. You did a fantastic job getting it up and running and ZIP is one of the most used file archivers there is. So if you should be very proud of yourself. It is quite an achievement.

Let me give you an example of why this is a very necessary UDF. I have a client I am writing an auto-updater for. This person's clients are restricted in what they can or can not install. So I can't ask them to install the 7-zip DLL. The program has to be self-contained. So ZIP it is. Also it has to figure out everything about where it was. Originally I wrote the whole thing in PHP because I had bought a PHP compiler called ExeOutput. However, ExeOutput does some really funky things to PHP which made it unusable. Because of this, I turned to AutoIt which I knew could do the same thing and I hoped AutoIt would have FTP and ZIP. Both of which are a part of PHP. To my surprise, the FTP UDF doesn't work unless you download the new UDF found in Bug #1970 and (of course) the ZIP UDF had problems also. But I would rather fight with those problems than try to write a C/C++/C#/C-/C^/Cv program because AutoIt is just that easy to write things in. So this UDF is essential and necessary in situations like what I am writing a program for and it needs to be fixed, released, and the distribution should contain it. Because it is that important. (Not to mention the FTP UDF as well.)

Oh! And one more thing - you can't download the 7zip_udf.zip file. None of the links work. Or at least - I can't read chinese but I didn't see a download link and the russian link doesn't work. So even if I wanted to download it - I can't! :-)

Edited March 15, 2012 by Enigma

[wraithdu]

Couple things to try:

- Try using the @AppDataDir macro

- Try setting explorer to show hidden and protected directories

- Make sure you are using : in your root path, and not accidentally :/ . The full path check is kinda dumb and just checks for :

[TheSaint]

I've experienced similar issues, and one day they magically cleared up, so I can only presume it was something to do with security & permissions.

[Enigma]

Hmmmmm..... I'm running on my own Windows XP box as an admin. So privileges are not the problem. Remember I said I am writing it for a customer who has customers that live on restricted boxes - but the problem is happening to me - haven't even gotten it to them yet. :-)

@AppDataDir - I just had a wrench thrown in to using that. The customer has said to put everything into the same directory they created because they know it can be read/written. So I am just using @ScriptDir.

May I suggest that if the _ZIP stuff doesn't like "/" that a StringReplace be put into each of the functions to automatically correct for this issue? I'll put it in to my copy immediately but if this is a known issue shouldn't you maybe/possibly make sure it doesn't happen?

:-)

In fact - here it is! :-)

Update: I just realized I saw something in the _ZIP file. You have "\\" instead of "\". Modifying my program and I modified the modifications I made to the _ZIP file. This might possibly be my problem. But the StringReplaces are now in also (and corrected for \\).

Update: That didn't work - put everything back to just using "\" instead of "\\" for the StringReplace.

Update: Removed the upload. Had to take all of the StringReplaces back out. When they were in I always got "not full path" errors. :-( What can I say? :-)

Edited March 16, 2012 by Enigma

[wraithdu]

Two replies to that:

1) In my version of the UDF the only places I have are in regex's, where they are required to be. If you've changed that, then you've broken something.

2) It's not my job to fix your broken paths, ie stringreplaces for /, so feel free to modify the UDF if you wish for your purpose, but please remove your attachment as I don't need anything else confusing this thread. Supporting one version is bad enough, thanks.

[Enigma]

Yeah, I didn't see your post until after I had removed it. But my changes did not make it work - it just made it worse. :-/ Oh well, gotta go to work. Interesting that fixing the "/" problem made it say "not full path" to everything. I'll have to look at this some more since if everything then comes down to just one error - that might be traceable. If I can figure out why that is happening then maybe the entire problem can be resolved.

Let me reply to your #2:

It is not "it is my job" to do anything. It is a question of having an actually fully functional UDF that you are presenting to the public at large. In writing programs I find that there is a line which some people draw in the sand. "I shall not go beyond this border," they say. Meaning the person feels as if they are doing too much for someone. The problem with this approach is that people depend upon your work to work correctly and to be smart enough to handle problems. It's like this guy at work. He is really smart, very good looking, and is trying to improve himself. He wants a girl friend but although he treats them nicely his attitude is that women are his footstools and he just can't figure out why every girl he meets dumps him. His attitude is "Well, it's their loss." or "It was meant to be. if they can do me when I want they aren't worth the time and effort". That is the attitude you are presenting in #2. Even though you know these routines have problems with "/" - you are saying we can all kiss your rear end because you won't make the UDF be smart enough to fix the problem if it occurs. Even though it is only a line or so of code to do this. My attitude is to ALWAYS fix problems I am made aware of. Because then I have happy customers and that makes me happy and I get paid. :-)

I do hope you change your mind about #2. But even if you don't I will be putting the StringReplaces back into the UDF here where I am and I will try to track down the "not full path" problem also. If I can fix that problem and get it working I will post again and let you know the changes that need to be made. Until then - gotta go to work! :-)

[BrewManNH]

It's really simple to use a StringReplace on the path string you're sending to the UDF to replace "/" with "", considering the UDF doesn't handle "/" as it is written. If it is a known functionality of the UDF, then it is incumbent upon the person using it to send the data in the correct format.

Look at almost any function, even internal AutoIt functions, and you'll see that the data has to be sent to them in the correct format or they'll fail. I encountered the exact same issue just today where someone had written a script that was trying to update a Date control by sending it the information in "Day of Week, Text of Month, Day of month, 4 digit year", when the function is described in the help file to only accept dates in "yyyy/mm/dd" format, and it was failing to set the date. Should the developers try and figure out a way to overcome an obvious misuse of the function because some user wants to send it data in the wrong format?

[wraithdu]

I can't say it much better than BrewManNH, except to add that / is not valid in any Windows path (we're not talking URLs here). You need to police your input to the UDF, same as for any other function internal or UDF. If you allow users to input their own data, then you must make sure it conforms to the platform / UDF / function / whatever requirements.

Beyond that, if there is a real bug I'll do my best to fix it, as I don't have any XP machines any more. Search around for the Graphical AutoIt Debugger, it may help you find the problem.

Edited March 16, 2012 by wraithdu

[Guest enigma2]

Ugh - hit the wrong thing - hate it when I do that! Now I have to retype everything again! :-)

Ok - I was at work and decided to check on this since I have been out in the wild doing things. Unfortuantely, my enigma account password is at home. So I made enigma2! :-)

Onwards:

wraithdu: I hate to burst your bubble - but Windows has been accepting slashes (/) since sometime around 2003. Microsoft made the change then because Linux had become very popular and people were complaining that the Macintosh now used slashes and Windows as the only older OS that did not. So they made it so you could use either. Try it. Bring up a directory dialog and type in C:/Windows/System32 and it will change to that directory. Even AutoIt will accept the slash in many of the functions. There are some it won't - but that's because they just haven't changed those routines/libraries. However, I have used slashes in FileRead and FileWrite with no problems at all.

wraithdu: Second - you do know that Windows NT, XP, Vista, and System 7 are all just Windows NT. If you look at the System information about your OS you will see that this is true. XP is (I think) Windows NT v5, Vista is NT v6, and 7 is NT v8. So you really shouldn't think of XP as an "old" system. It is really just a different version of the same OS. That's why, if you don't tie your software to specific things found only in System 7 or Vista - your software will run on XP without a problem. It is only when you use the "special features" of System 7 that you will find that your program won't run under XP. And by "special features" I mean the ones Microsoft put in specifically to run under System 7 only. I was an early user of System 7 and it ate my hard drive. Literally. There was this 50,000 updates download from Microsoft and after that finished the hard drive died. Within a day or so Microsoft had another download that fixed "problems" with the earlier download. At that point I decided to go back to XP and have been very happy ever since. :-) I am also an advocate of keeping XP updates going with Microsoft past the 2014 deadline since there really isn't anything wrong with XP - except Microsoft doesn't make a lot of money off of it anymore.

BrewManNH: Ah. So now you are saying "If I put it in the documentation - I don't have to fix it". Er....no? I can put in my documentation "I don't pay income taxes" but I don't think the IRS will let me do that. Or to put that another way - just because you KNOW there's a problem and SAY there's a problem - it doesn't absolve you of trying to remove such problems. Now - YOU - may not want to fix the problem. Which is perfectly ok. But if someone comes along, sees the problem, and figures out how to fix it - you should be willing to accept the changes to make the product better. Otherwise, if the changes do improve the product (and that is important that the changes are not harming the product) and you won't accept them - then there is a problem. Not with the product - but with you. Because then you are the person who is not only blocking the changes that will make the program better - but you are also the person who is standing in the way of everyone else moving forwards. Now. This isn't to say that you - or me - or anyone else - should go to extremes. A flat, outright, denial of allowing any updates is an extreme. But a total acceptance of anything given to you is an extreme as well. You have to have a happy medium where you look at, consider, and if the changes do improve the product without harming it, you use them. I also want to point out the obvious. I am very sure your mom - at some point in time - has said you something like this: "If everyone else jumped off of a cliff - would you jump too?" To show you just how dumb it is to follow the crowd just because the crowd is doing something. The same holds true for AutoIt and the UDFs. If the rest of AutoIt just dumps on the usage of slash versus backslash - and you know it - should you be just like everyone else and not care a bit that this problem isn't handled properly? Or should you try to improve the product so - unlike everyone else - your product does work properly? Think about it. :-)

Valik Edit: This post was composed by enigma2 which was a second account for Enigma. I deleted the engima2 account which is why it shows up as a guest.

Edited March 20, 2012 by Valik

[wraithdu]

I'm done with this debate frankly. I'm not changing the UDF. It responds properly to your input, with an error. If you find some other problem or real bug, I'd be happy to entertain that discussion with you.

An unrelated warning though... multiple accounts are against forum rules. I would quickly PM a mod and clear it up before you get both accounts blocked.