5 ms·

> People who don't know any better alternatives continue to use it Genuine question: what are the better alternatives?

by AlexandrB 6y ago

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
breakfastduck 6y ago
Yep, +1 for 7zip
PrimeDirective 6y ago
7zip (the archive manager, not the compression format), at least for Windows
theandrewbailey 6y ago
Peazip: https://peazip.github.io/ https://peazip.github.io/ 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.
- WayToDoor 6y ago
  Is a file move that big of an IO operation?
  - vore 6y ago
    I run into the issue sometimes cross-volume, where the file gets extracted into a temporary directory then has to be copied to the actual destination, into e.g. a network volume or second hard disk.
  - theandrewbailey 6y ago
    Back when I used Winzip/7zip, they didn't move files: they copied files. When you're working with files measured in gigabytes, the speedup is quite noticeable.
  - iMerNibor 6y ago
    If it's moving it to a different drive/partition it'll have to copy it again Moving many (small) files can also be quite slow
  - sumtechguy 6y ago
    depends on the move operation. 1 file you would not notice it. Thousands it would add up. Across 2 physical drives you may also notice it if the file is big enough.
- jasperry 6y ago
  In response to WayToDoor, some archives contain thousands of files, and it's essentially doubling the number of filesystem operations by putting them in a temp directory and then moving. If the temp directory is on a different drive from the destination, then it's recopying all the data. 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.
saxonww 6y ago
For zip files in particular, you can just right click and 'Extract all' in modern versions of Windows. I believe you can also double-click to open them like folders in Explorer. 7-Zip covers the majority of other formats you're likely to encounter.
pbalau 6y ago
TotalCommander.

> People who don't know any better alternatives continue to use it Genuine question: what are the better alternatives?

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

breakfastduck 6y ago

Yep, +1 for 7zip

PrimeDirective 6y ago

7zip (the archive manager, not the compression format), at least for Windows

theandrewbailey 6y ago

Peazip: https://peazip.github.io/ https://peazip.github.io/ 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.

WayToDoor 6y ago
Is a file move that big of an IO operation?
- vore 6y ago
  I run into the issue sometimes cross-volume, where the file gets extracted into a temporary directory then has to be copied to the actual destination, into e.g. a network volume or second hard disk.
- theandrewbailey 6y ago
  Back when I used Winzip/7zip, they didn't move files: they copied files. When you're working with files measured in gigabytes, the speedup is quite noticeable.
- iMerNibor 6y ago
  If it's moving it to a different drive/partition it'll have to copy it again Moving many (small) files can also be quite slow
- sumtechguy 6y ago
  depends on the move operation. 1 file you would not notice it. Thousands it would add up. Across 2 physical drives you may also notice it if the file is big enough.
jasperry 6y ago
In response to WayToDoor, some archives contain thousands of files, and it's essentially doubling the number of filesystem operations by putting them in a temp directory and then moving. If the temp directory is on a different drive from the destination, then it's recopying all the data. 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.

saxonww 6y ago

For zip files in particular, you can just right click and 'Extract all' in modern versions of Windows. I believe you can also double-click to open them like folders in Explorer. 7-Zip covers the majority of other formats you're likely to encounter.

pbalau 6y ago

TotalCommander.