> People who don't know any better alternatives continue to use it
Genuine question: what are the better alternatives?
Genuine question: what are the better alternatives?
I used to use 7zip, but switched when I discovered that Peazip doesn't extract to a temporary directory when extracting (thus, saving extra I/O work). It directly extracts into the target directory.
Moving many (small) files can also be quite slow
I thought the creation of the files in the temp directory was an unavoidable artifact of how drag-and-drop worked in Windows. If peazip can get around this, I might check it out.
7-Zip covers the majority of other formats you're likely to encounter.
I think that they also support more archive formats and they even have their own open format 7z.
Based on their own claims, there are also faster and more efficient than Winrar.
I'm amazed at all the comments calling for 7zip as the one and only. winrar works just fine so does windows zip function. If you have an edge case, yeah then you need something that can handle it.
This is the biggest joke of win32 system, how on earth after so many decades of breaking things this is still default?
The size of the field in these APIs is a fixed maximum length and can't be changed, because that would break everything. If an app called into the kernel and got a string longer than 260 chars back, then boom, instant buffer overflow.
There are other, newer Win32 APIs for all of these that don't have that limitation, but apps have to be changed to use them.
But, they're only accept file paths this long if those paths begin with the magic sequence \\?\ [0]. So each "normal" path has to be "normalized" to this format in order to be longer than 260 characters. This is a usually a trivial operation of appending this sequence, but it's slightly much complicated than it looks, and also not well known for some reason.
I'm not aware of any newer APIs that can natively accept long path names, btw,
The Windows Explorer shell, and so the standard Open File dialog used by most application, uses the "non-normalized" form without the magic prefix, and so can't be used to view, delete or create those long paths. So to bring this discussion back to the original post: 7zip is very good to have on your system if only to be used as a viewer for files on those long paths, and in order to delete them, since Windows explorer can't...
Incidentally, the other common application which can handle long paths is git for windows.
As for the much hyped ability in Windows 10 to enable the support natively : it's still not enabled by default, so you can't count on it being present on user's machines.
BTW, I'm using an open source library for dotnet called Zeta Long Path, which does exactly this (appending this magic sequence) and works wonderfully well, even on Windows XP. But you're right that most people who use those APIs directly usually allocate a 260 char array and use it, and if Microsoft would suddenly change the behavior and started returning actual long paths then those applications would blow up.
[0] https://docs.microsoft.com/en-us/windows/win32/fileio/naming...