Stan Brown <
the_stan_brown@fastmail.fm> wrote:
My Win 10 File Explorer has started treating zip files as folders
instead of files.
In Settings » Apps » Default apps » Choose default apps by file type,
7-zip is associated with the .zip type, with a black-and-white icon
of "7z" inside a box. If I double-click a .zip file in File Explorer,
it opens in 7-zip.
However, in Windows Explorer the .zip file's icon is a yellow folder
with a blue-and-white "z" superimposed. That's trivial, but in the
left-hand panel (called Navigation Pane), Explorer shows every
.zip file as if it were a folder. Since I have an archive directory
with dozens of .zip files in it, the actual subfolders are pushed
way off the bottom edge of the window.
I tried re-registering .zip files in 7-zip's Tools » Options, then
restarting Explorer; no change. I tried again, running 7-zip as administrator; no change.
Though restarting Explorer is usually enough for these sorts of
changes, I even did a full system restart; still no change.
How do I tell Windows 10 that .zip files are files, not folders?
Zip file integration has been around since Windows XP using the
zipfldr.dll for exported functions available to Windows/File Explorer.
https://www.vistax64.com/threads/zip-file-compressed-folders.93827/
That article mentions editing the registry to enable/disable zipfolder
support in Windows. The .reg files are just text files, so you can view
them before committing their changes to the registry.
I haven't bothered to disable zipfolders in Windows (not at 10), and
I've always had a 3rd-party zip tool, like Peazip (which is a fork of
7-zip, but with a better GUI, and added features).
Used to be programs could edit the registry to make changes to filetype associations. Malware did that, too. So Microsoft changed Windows 10
to make many filetypes protected. You cannot edit the registry to
change them. Programs cannot directly edit the registry to change them.
The config wizard in Win10 must be used, because it knows how to
generate a valid hash for the UserChoice registry key. In Win10, enter
"assoc" and pick "choose a default app for each type of file". In the
"Choose default apps by file type" dialog, scroll down to the .zip
filetype association. For me, Peazip is shown as the external handler
for that filetype. Clicking on Peazip, or whatever is currently
selected, shows you a list of registered handlers for the filetype.
Looks like you already went there to check the .zip filetype association
for what handler gets used to open a .zip file. Making selections
inside of the 7-zip program itself won't work.
That's for selecting the handler to open a filetype. If you go to:
HKEY_CLASSES_ROOT\.zip
You'll see the (default) data item points to the handler. For me, it
specifies PeaZIP.ZIP. But under the CompressedFolder/ShellNew subkey,
it still lists zipfldr.dll. That's what File Explorer uses to display
those object types.
To see specifics on the PeaZip.ZIP filetype association for .zip, I look
at:
HKEY_CLASSES_ROOT\PeaZip.ZIP
That shows which resource is used to display an icon (when the file is
treated as a PeaZIP.ZIP filetype). The icon could be a separate .ico
file, as for Peazip, or it could be an index to a resource inside a .dll
or .exe file.
I suspect changing the icon for the .zip handler only affects the
right-pane view showing files. The icon would show next to the file in
the file list. The "folder" in the tree pane is still using the shell
icon defined for use by Explorer, and that's still using zipfldr.dll.
For example, I have many .zip downloads for FMs (Fan Missions) for
various Thief games, and Darkloader which is Thiefsie-like. In the
right-pane file list, the Peazip icon is shown next to each .zip file.
In the tree pane of Explorer, a folder object icon is shown, because zipfldr.dll is still getting used for Explorer's shell icon. So, I can
use File Explorer's zipfldr handling of .zip files to let me navigate
into .zip files without having to first extract them. I can see files
and subfolders inside the .zip file without having to first use Peazip
to extract the .zip file to dump the files and folders within to
someplace to then see them nor do I have to load Peazip to look at the
TOC (Table of Contents) of a .zip file to see what is inside a .zip
file.
I get the best of both: File Explorer lets me drill into .zip files
starting in the tree pane to select the .zip file shown as a folder, and
then drill further using the right-side file pane. I could use Peazip
to do the same to drill into a .zip file to look at files and folders
within, but I would have to separately start Peazip. I can use either
to extract files and folders from within a .zip file.
If you disable zipfldr.dll, like deregistering it, File Explorer won't
show .zip files as folders any more. You won't see a .zip file as a
folder object, and won't be able to drill into the .zip file to see what
files or folders are inside.
If you were to make the 7-zip and zipfldr.dll icons the same, you
couldn't tell which handler is used on a .zip file. Could be 7-zip, or
it could zipfldr integration in File Explorer. If the confusion is too
great on which handler is doing what on a .zip file, disable zipfldr and
rely solely on your 3rd-party archive file handler.
Here is some detailed info on zipfldr.dll:
https://windows10dll.nirsoft.net/zipfldr_dll.html
Windows XP users could use:
regsrv32.exe /s /u C:\Windows\System32\zipfldr.dll
regsrv32.exe /s /u C:\Windows\SysWOW64\zipfldr.dll
to deregister the zipfldr.dll file thus removing its integration with
Windows Explorer. In later versions of Windows, there is no dllunregisterserver entry point in the DLL, so it cannot be deregistered
(to remove finding via registry).
https://www.sevenforums.com/customization/3989-how-disable-zip-folder-zipfldr-dll-post36679.html#post36679
mentions the lack of an entry point in the DLL for deregistering it.
Other than the registry edits mentioned above, the other option is to
rename or move the file, but I suspect you'll start seeing errors in the
Event Viewer log. Something expecting to find something, but failing,
probably incurs some overhead, like error reporting, or the time trying
to issue a function to a DLL that doesn't exist anymore.
zipfldr.dll, as per the nirsoft article, has 2 static icons. Indexing
starts at zero, so the registry entry of:
HKEY_CLASSES_ROOT\.zip\CompressedFolder\ShellNew
shows "zipfldr.dll,-10194". Likely the first icon at index 0 gets used
in File Explorer. What I see in File Explorer's tree (navigation) pane
is the zipfolder is shown using the file.zip name using Peazip's icon,
but subfolders are shown using the standard folder icon. That's because
the subfolders are not .zip files. They're folders inside the .zip
file, not .zip files inside a .zip file. File Explorer shows the .zip
file as a folder in the tree pane, and, for me, its icon is whatever
archive handler I installed (Peazip, for me). When File Explorer is
showing you what is inside a zipfolder, that's just the files and
folders within (and those are not .zip files unless you zipped a zip
file to bury a .zip inside a .zip). What I see in the tree pane is:
:
|__ Thief1Gold-FMs
| |__ <p> 64five.zip
| | |__ <f> Books
| | |__ <f> intrface (*)
| | |__ <f> mesh (*)
| | |__ <f> strings
| |__ <p> A_Dark_Secret.zip
| | |__ <f> Books (*)
| | |__ <f> intrface (*)
| | |__ <f> strings (*)
| :
|
|__ Thief2-FMs
:
<p> Icon for Peazip.
<f> Standard folder object icon.
(*) These have subfolders, but they are NOT automatically expanded when
I open the zipfolder, or when I open any folder. When I open a
folder, just what subfolders are under there are shown.
If File Explorer showed only <p> icons on every zipfolder, and all its subfolders, it would be misrepresenting which were zipfolders. The .zip
file is a zipfolder, and the others are just subfolders (folders inside
the .zip file), not more .zip files inside a .zip file.
If I decided to disable zipfldr.dll integration with File Explorer, I'd probably see just see the following in the tree pane:
:
|__ Thief1Gold-FMs
|__ Thief2-FMs
:
File Explorer couldn't drill into the .zip files in its tree pane
without the assistance of zipfldr.dll.
When I am in File Explorer, and .zip files are shown as folders in the
tree pane, there is no thousands of files and subfolders that
automatically populate the tree pane. When you open a zipfolder, only 1
level is shown underneath. You would have to open more subfolders. As
with ANY folder shown in File Explorer, if you don't want to retain a
view of all subfolders under a folder you selected, deselect the folder.
It's your choice which folders remain expanded or collapsed. This not
behavior unique to zipfolders. File Explorer works the same way for ALL folders (with subfolders) in its tree pane.
If you select a .zip file in File Explorer, and it is showing thousands
of [sub]folders inside the .zip file, well, that's because that is how
the .zip file was organized: a single tier of folders, and lots of them. Without dealing with .zip files, just use File Explorer to open, say,
the C:\Program Files or C:\Programs Files (x86) folder. File Explorer
will expand the tree to show EVERY subfolder under those parent folders
all at once.
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)