I have a problem with unzipping files. Usually I use a PowerShell script, that I run through SQL Server database (procedure) and it will unzip my files how I want them (database shouldn't be any issue).
Main part of script:
exec '"for %i in ("'+#path+'\*.zip") do "C:\Program Files\7-Zip\7z.exe" x "%i" -o"'+#to+'""'
But for once in a while there is a .zip file that if run through this script will extract files with names of files encoded badly and to prevent that I need to manually open every .zip file and click to extract in 7-zip GUI and that will returns names of files correctly.
This manual way of doing things very, very slow. Because it needs to be done on a server, God forbids if I am on VPN at home. So let's say I have 5 zip files (3 GB), it will take me hours to unzip. If I do it, through server it takes like 2 minutes.
So I just trying to find out how to unzip it with script, what is the difference between my script and manual extraction?
The root-cause is likely to be files that were created with a setup that doesn't match the codepage of your windows environment. Are any of the zip file publicly available? If so, can you provide a link?
To deal with these problem files, you need to know what encoding was used for the filenames. If the 7z gui can handle these files automatically there must be an option to tell it what encoding to use.
Once you know the encoding you can use the -scs option in 7z to decode the filenames correctly.
Modern zip files don't have this issue because they store filenames in UTF-8.
I am starting to learn about databases and I have seen in the documentation (https://www.postgresql.org/docs/current/app-pgdump.html) that I can have an output of the pg_dump in either script or archive file format.
My question is, why would I choose an archive over a script format and another way around?
Is it only about the fact, that with archive files I can choose which part of the database should be restored with pg_restore? And if archive format seems to be more flexible than script format why would I ever choose to use script files instead?
We are looking for an approach to extract our application JARs and resources from an EXE installer built with install4j. We are trying to automate installers testing though without actual installation - we want to run our application main JAR unpacked from an installer.
With help of PE file format parser https://github.com/kichik/pecoff4j I've found the major part of content is placed in some kind of preamble of an image. The same entry with the same size is shown when I opened the installer in 7-Zip:
But the format of the entry is unknown to 7-Zip and I can't to go deeper. When I opened the entry in a hex editor I found some of the application resources content, classes names, etc.
The question is - what is a format of the entry and how can I parse it?
P.S.: It seems there should be no issues with DMG for Apple and SH for Linux - as they are regular archives and I hope I can read them in my Java code.
This is not a documented format, it is internal to the installer. You could build an additional Windows ZIP archive media file and extract that. It will have the same contents as the installer.
I have several large zipped folders in my cloud storage drive. I want to transfer a specific file from each of the zipped folders to my local hard drive (I cant copy all of them since i dont have enough space). Is there a way to do this using command line/cmd or powershell. I am using Windows 10 (Build 18362).
The file name is the same so i was hoping if i can write a loop to do this.
I calculated MD5 and SHA256 hash values of notepad.exe and mspaint.exe through online hash generators md5FileCalculator Onlinemd5.
What i noticed is that if i calculate when both exe's are present in their actual postion in system32 the value coming is different than when placed somewhere out of system32 folder.
What is the reason behind that ? Which is the correct hash value ?
I am using Software Restriction policy to block the applications, I created a hash rule for notepad.exe(present in SYSTE32 folder) file and blocked it. When I check the hash value in registry it is different from the hash value of notepad.exe (from SYSTEM32 folder) calculated through other methods like online md5 calculators or through Windows API. But when I copy the notepad.exe file into some other folder say on desktop and calculate the hash value, it is coming same as it is in registry for which I created the rule.So the correct value is I think the one which I get when file is out of system32 folder. But I am not getting why it is happening ? Does it have something to do with permissions ?
It's because of 32-bit applications running on 64-bit Windows, and how Windows handles the System32 folder for those programs.
This was also driving me nuts for a while because I couldn't for the life of me figure out why certain files in System32 (namely .dlls and .exes) were returning different hashes depending on what I checked them with.
Using HxD and Firefox to upload a file to check its hash, I got different results compared to using QTTabBar's hash checker, which runs inside explorer.exe.
But if I copied one of these files to another location, I would then get identical results across all programs.
Meanwhile, HxD showed different file lengths for the copied file vs the one in System32, and while both showed similar byte distribution, there were also significant differences.
But then I thought to try the same thing on another folder, and finally cracked it, with a little help from Wikipedia:
The operating system uses the %SystemRoot%\System32 directory for its
64-bit library and executable files. This is done for backward
compatibility reasons, as many legacy applications are hardcoded to
use that path. When executing 32-bit applications, WoW64 transparently
redirects 32-bit DLLs to %SystemRoot%\SysWOW64, which contains 32-bit
libraries and executables.
32-bit applications are generally not aware
that they are running on a 64-bit operating system. 32-bit
applications can access %SystemRoot%\System32 through the pseudo
directory %SystemRoot%\Sysnative.
Because HxD and Firefox (and most other browsers) are all 32-bit applications, when you load a file into them, Windows is actually transparently redirecting them to the file of the same name in the SysWOW64 folder (presumably if you ran a 64-bit browser, you would not encounter this problem).
Similarly, when you copy a file out of System32 to another location, explorer.exe, being a 64-bit process, copies the original System32 file, and not the (confusingly named) SysWOW64 equivalent.
So as the wiki states, if you enter %SystemRoot%\Sysnative
into the path of the open file dialogue in your 32-bit application, it should load the file from the real System32 folder, and give you the correct result.
And if you check the files in the SysWOW64 directory, all files should return the same respective hashes regardless of what you open them with.
Further reading:
SysWOW64
Sysnative
Are you sure you're checking the exact same file yet on diferent paths? I think you're checking two diferent notepad.exe. Check the size of the file... it must be exacly the same on bytes.
I've just checked my notepad.exe on two distinct paths C:\Windows\System32 and C:\Windows and they are diferent.