feat(archive): support non-overwrite decompress

[KirCute]

Description / 描述

为解压添加“覆盖现有文件”选项

前端：OpenListTeam/OpenList-Frontend#285

Motivation and Context / 背景

How Has This Been Tested? / 测试

Checklist / 检查清单

• I have read the CONTRIBUTING document.
  我已阅读 CONTRIBUTING 文档。
• I have formatted my code with go fmt or prettier.
  我已使用 go fmt 或 prettier 格式化提交的代码。
• I have added appropriate labels to this PR (or mentioned needed labels in the description if lacking permissions).
  我已为此 PR 添加了适当的标签（如无权限或需要的标签不存在，请在描述中说明，管理员将后续处理）。
• I have requested review from relevant code authors using the "Request review" feature when applicable.
  我已在适当情况下使用"Request review"功能请求相关代码作者进行审查。
• I have updated the repository accordingly (If it’s needed).
  我已相应更新了相关仓库（若适用）。
  • OpenList-Frontend #XXXX
  • OpenList-Docs #XXXX

[davidtuning]

@KirCute, thanks for fixing the problems with part files that have a dot (fix.lock.part1.rar) in their file name. But now that I got time to test it, there's a new problem, maybe because of the regex?
When you have different part files in the same folder, they will fail to open or uncompress (because it will fail to find the next part file).

It will fail with another part files in the same folder:

Test.part1.rar
Test.part2.rar
Test.part1.rar

Work.part1.rar
Work.part2.rar
Work.part1.rar

File.part1.rar
File.part2.rar
File.part1.rar

It will work with only part files of one archive in the folder:

Test.part1.rar
Test.part2.rar
Test.part1.rar

You will need to move/have them in individual folders in order to open or uncompress said files; before, it worked just fine.

Another thing, sometimes when uncompressing or streaming zip files, memory could double or more than the zip's original size. So it makes it impossible to uncompress files bigger than the actual RAM of the systems, it's strange because zip support random reads.

And sorry, mods. Next time I will probably write a issue ticket. I'm used to write this kind of short problem on PR's.

[KirCute]

Another thing, sometimes when uncompressing or streaming zip files, memory could double or more than the zip's original size. So it makes it impossible to uncompress files bigger than the actual RAM of the systems, it's strange because zip support random reads.

I noticed that the upstream library alexmullins/zip has the memory overflow issue you mentioned when extracting large ZIP files, and this was resolved in alexmullins/zip#22. I specifically merged this fix into my own fork. However, as you mentioned, it seems that after doing so you're experiencing this issue instead. I'd like to know whether this problem existed in version 4.1.6 and earlier versions (specifically before #1599 was merged).

[davidtuning]

Edit:
Sorry, I just wake up, and reply without nothing you tagged the memory overflow issue. But yah, I'm still experiencing the same problem after the PR

It was introduced with #1599; that's why I mentioned that it used to work before (I forgot to tag the PR, sorry!).

After a bit more testing, it looks like it opens/uncompresses the last part1.rar file in the folder correctly.

[KirCute]

Edit: Sorry, I just wake up, and reply without nothing you tagged the memory overflow issue. But yah, I'm still experiencing the same problem after the PR

It was introduced with #1599; that's why I mentioned that it used to work before (I forgot to tag the PR, sorry!).

After a bit more testing, it looks like it opens/uncompresses the last part1.rar file in the folder correctly.

That's really strange. alexmullins/zip#22 seems to work fine for me. I'll test it out separately with files compressed using different operating systems and different archiving tools later.

[davidtuning]

Right, zip without password works well, before and after the PR #1599 but zip with password still have the memory overflow issue for me.