7zip creating a file larger then the folder I'm zipping
A free file archiver for extremely high compression
Brought to you by:
ipavlov
So I have the latest version installed on Server 2012R2 and it's always worked good. Today I went to compress a filer that 2.8GB is size and 7zip showed a total size over 50GB. My drive only has 36GB so obviously it wouldn't even create the file. I've tried zipping folders a little under 2GB and they compress just fine.
Any idea?
I don't understand that case,
Please describe all actions, selected options and clicks, and show some screenshots.
Here are some screen shots showing my issue. Hopefully they explain it better.
C:\Users
folder is not usual folder. It has many junction point folders.- run 7-Zip File Manager,
- open the folder
C:\Users\your_user_name
in 7-Zip File Manager.- press
F3
. It will calculate size of each folder.- click
Size
column with mouse. It will sort folders by size.- look content in folders with big size.
Last edit: Igor Pavlov 2023-05-05
I know it's not a usual folder to zip, but I've done probably 20-30 and never had this problem before. It could be that this users folder had more junction points then the others I've done. I'll try your suggestion.
Thanks.
I found the largest culprit in that directory. Deleted the junction and now the compressed size is around 13GB. Good enough so that I can zip it and be able to delete the users account and folder.
Thanks.
So why Explorer showed only 2.8 GB?
Did you check subfolders sizes in explorer?
Last edit: Igor Pavlov 2023-05-05
Explorer showed a little over 1GB after removing the 1st junction point. Obviously there's still more junction points, but at least it's down to a compressible size. The drive I save the zip files to has more then enough space so I'm not gonna hunt for any more.
Thanks.
Why there is difference in size in Explorer and 7-Zip for some subfolder?
Why explorer don't show real size while 7-zip can show it?
If it's junction point, where to does it link?
So basically it looks like the junction point pointed back to itself. What looks to have happened is the the 'Application Data" (not appdata) folder in that users folder went from a shortcut to nowhere (which is how Server 2012 and newer o/s handle that legacy folder) to an actual folder. And inside of that folder was a copy of every folder (and files) in the users folder. And inside the "Application Data" folder in the subfolder was a copy of the contents in the original "Application Data" folder and that continued for at least 8 iterations in the 7z file manager before I got an error message (don't recall what the message was, just that file manager wouldn't open that folder any further) . Windows saw it as a junction point however 7z file manager was able to see the actual files. It could have gotten screwed up when our outside IT company moved the server from our Esxi host to the Hyper-V host. It's the only folder that has the problem with the application data folder anyways.
There is probably still more junction points in that users folder, but I wasn't about to look any further as it was small enough to zip. I'll deal with any problems as they come up if I ever have to unzip that users folder in the future.