5 ms·

7zip

by geogra4 6y ago

7zip

Semaphor 6y ago
I haven’t used WinRAR in ages, but what makes 7zip (which I use as well) better?
- greatgib 6y ago
  7zip is completely free and OpenSource, and more modern. 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.
  - moogly 6y ago
    Don't know about modern. Isn't the developer (Igor?) (in)famously against anything invented after 1998?
- olvy0 6y ago
  It can extract files to paths of more than 260 characters, without any extra tools or registry hacks, on any version of windows (even xp). Winrar cannot. As a bonus, 7zip can also delete folders with file paths that are over 260 characters from its file manager ui. It has been one of the only programs to be able to do so for many years.
  - Seanambers 6y ago
    Amount of times this has been an issue with using Winrar for 15+ years : zero. 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.
    - olvy0 6y ago
      FWIW I agree with you, personally I also prefer Winrar, and have used it for many years with zero issues. I like its ui better than 7zip's. But the 260 chars is the one edge case that happened to be important to me and so I decided to switch.
    - olyjohn 6y ago
      WinRAR works fine. But it's $29. 7zip works fine and is not $29.
  - xfer 6y ago
    > paths of more than 260 characters This is the biggest joke of win32 system, how on earth after so many decades of breaking things this is still default?
    - KiwiJohnno 6y ago
      To be clear, this is a limitation in some of the very old Win32 APIs, not the kernel itself or the filesystem. 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.
      - olvy0 6y ago
        You're right in that the limitation isn't in the kernel or the file system, but it's not in the API either. Even the oldest functions in the Windows API can accept long filenames, up to 32,767 characters. This has been possible since Windows NT, for about 20 years now (I think). 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-a-file?redirectedfrom=MSDN#maximum-path-length-limitation https://docs.microsoft.com/en-us/windows/win32/fileio/naming... [1] https://github.com/UweKeim/ZetaLongPaths https://github.com/UweKeim/ZetaLongPaths

7zip

Semaphor 6y ago

I haven’t used WinRAR in ages, but what makes 7zip (which I use as well) better?

greatgib 6y ago
7zip is completely free and OpenSource, and more modern. 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.
- moogly 6y ago
  Don't know about modern. Isn't the developer (Igor?) (in)famously against anything invented after 1998?
olvy0 6y ago
It can extract files to paths of more than 260 characters, without any extra tools or registry hacks, on any version of windows (even xp). Winrar cannot. As a bonus, 7zip can also delete folders with file paths that are over 260 characters from its file manager ui. It has been one of the only programs to be able to do so for many years.
- Seanambers 6y ago
  Amount of times this has been an issue with using Winrar for 15+ years : zero. 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.
  - olvy0 6y ago
    FWIW I agree with you, personally I also prefer Winrar, and have used it for many years with zero issues. I like its ui better than 7zip's. But the 260 chars is the one edge case that happened to be important to me and so I decided to switch.
  - olyjohn 6y ago
    WinRAR works fine. But it's $29. 7zip works fine and is not $29.
- xfer 6y ago
  > paths of more than 260 characters This is the biggest joke of win32 system, how on earth after so many decades of breaking things this is still default?
  - KiwiJohnno 6y ago
    To be clear, this is a limitation in some of the very old Win32 APIs, not the kernel itself or the filesystem. 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.
    - olvy0 6y ago
      You're right in that the limitation isn't in the kernel or the file system, but it's not in the API either. Even the oldest functions in the Windows API can accept long filenames, up to 32,767 characters. This has been possible since Windows NT, for about 20 years now (I think). 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-a-file?redirectedfrom=MSDN#maximum-path-length-limitation https://docs.microsoft.com/en-us/windows/win32/fileio/naming... [1] https://github.com/UweKeim/ZetaLongPaths https://github.com/UweKeim/ZetaLongPaths