一个 100G 的 .zip 。。解压需要很长时间。每次到中途遇到网络中断,bandizip 就玩退出。。。。吐血。。。
只能复制到本地再解压。但是本地只有 256G (的确很傻) 不够放。。。
有啥 zip 遇到错误能自动重试,而不是退出?
![]() |
1
Shatyuka 9 天前
要不远程到 NAS 上解压呢?
|
2
xziar 9 天前
大部分程序没考虑过打开的文件句柄失效后优雅地重试吧……
解压遇到同名文件跳过不就好了。如果是单个文件,那就直接在 NAS 端解压吧,反正解压不怎么吃 cpu 的 |
4
dford 9 天前
有什么困难的点吗,unzip 一下不行吗
|
5
1145148964 9 天前
why not 7z
|
![]() |
6
est OP |
8
MacsedProtoss 9 天前 via iPhone
完全不懂你这个是在搞什么…
是不是完全不会 Linux 啊 你 ssh 上去 unzip 一下不就完事了… |
![]() |
9
est OP |
10
tjmxf 9 天前 via iPhone
插个移动硬盘先把文件拉过来? 或者 nas 上解压后如果文件能拆小压缩拆成小份?
|
11
kujou 9 天前
我经常使用 wifi 压缩和解压超过 100G 的文件,我用 winrar 也很容易出现中断,这有这台 wifi5 ac 的无线会出现,另外两台 wifi6 ax 和插线的,都很正常,没有遇到过。后来我启用了 smb3.0 的多通道之后,所有设备也再没遇到过这种情况了。
|
![]() |
12
loveyu 9 天前
我猜测你是这样的,在 nas 的 smb 上有个 100G 的 zip 文件,使用 bandizip 在 windows 上解压时出现网络错误。
先假设里面是一堆文件而不是一个,你可以让 ai 写一个脚本先读取文件列表再逐个解压,本地维护一个已经解压的文件列表就行。 或者 100G 而已,一个 USB3.0 移动硬盘复制就十几分钟而已,然后回来解压 |
![]() |
13
yutou527 9 天前
先去解决网络错误问题吧,是环境特殊吗,必然经常网络中断
|
14
zsh2517 9 天前
#3 @qgswzmz nas 可以 ssh 上去吗,可以的话,命令行,unzip ,或者 7z cli ( https://www.7-zip.org/download.html )?不是一定要 GUI 或者 webUI 的。
如果是一次性的需求,找 AI 写一条命令,传一个小文件调试,几分钟能解决 如果是周期性的需求,更应该命令行脚本化+定时任务 --- 另外,如果我没记错,smb 、zip 好像都支持一定程度的随机读取,如果只是需要解压后的某一部分文件,理论上应该是能部分解压的,会快一点 |
15
MacsedProtoss 9 天前 via iPhone
@est 没看懂你在说啥 第一句话 远端解压传输很慢 第二句话远端解压传输少 你这不是自相矛盾吗???
如果你是说解压完之后传输总量变大 这不是废话吗 除非完全没有压缩否则肯定解压之后变大啊 而且小文件传输肯定是会比单个大文件要慢 |
16
zsh2517 9 天前
@zsh2517 如果是某些没有包管理工具的 Linux (比如之前帮人看过一个绿联旧版系统,基于 Linux 但是没有任何包管理),且官网下载缺少 glibc 。
我找到了一个静态链接版本(不受系统 C 库影响,理论上任意 x86_64 Linux 可用),未测试。看起来可能可以 https://github.com/justdan96/7zip_static/releases/tag/23.01 |
17
Bingchunmoli 9 天前 via Android
@est 所以 ssh unzip 不是远端吗
|
18
yc8332 9 天前
这种只能是 nas 本地解压。。
|
19
zsh2517 9 天前
刚看到下面的评论,这个 nas 不是内网的吗?内网一般传输速度比压缩/解压都快。不过既然提到传输很慢,那不是内网感觉没啥好办法了
看看能不能换压缩格式 ,gzip 是支持流式压缩解压的,理论上可以在不占用额外空间的情况下,实现断点续传+实时解压。但是 gz 只管压缩不管打包,算上打包(常见是 tar )可能又不能流式了 详细说一下需求和文件内容,比如文件类型(无压缩内容,如文本、wav 等原始媒体;有压缩内容,如 docx, mp4, mp3, jpg 等)、文件数量(少量大文件/大量小文件)等,看能否针对性的做一下处理 |
![]() |
20
ferock 9 天前
op 的意思是,源文件,在远端,解压缩结果到本地。。。。
那断网就是没救了呀。。。你还想断点续传啊。 想太多系列。 |
![]() |
21
gujuji 9 天前 via iPhone
太苦了,这样折腾,我是 6t ,我放在云盘
|
22
pxiphx891 9 天前
我建议你买一块 1TB 的移动硬盘
|
23
pxiphx891 9 天前
我查了一下 windows 也支持管道和 tar ,你可以试试 curl xxx | tar -xz 这种方式
|
24
NoOneNoBody 9 天前
怎么感觉这帖子和 OP 的人设不符啊,OP 应该是从事 IT 多年的人了
|
![]() |
25
mikewang 9 天前 via iPhone
这种情况网不行也没什么好办法啊,网络会中断就先解决网络问题。
或者 NAS 和电脑之间套一层 WireGuard ,物理链路中断时,WireGuard 并不会断,等恢复就好了。 要么就 NAS 电脑网线直连,配静态 ip 传输。 要么就把电脑硬盘拆下来,塞 NAS 里内部传输。 |
![]() |
26
opengps 9 天前
别转移问题,你自己说了是本地硬盘不够,硬要给解压软件增加功能真的没必要
|
27
kome 9 天前 via iPhone
把.zip 下载到本地,部分解压,然后删除.zip 中已解压的部分,然后再继续部分解压,继续删除已解压部分,依次循环直至完全解压。
就纯看有没有耐心了。 |
![]() |
28
est OP @NoOneNoBody 真没折腾出来。哈。broken pipe 之后一般软件都退了。
其实二楼已经说得很明白了。我这里需要 句柄失效之后能优雅重试的解压软件。 smb 是支持 seek 的,理论上你弄一个 while true 死循环一直去重试打开这个 .zip 解压是可以解决网络中断 smb 失效问题的。 @mikewang 我猜网络不断,但是解压的文件读写操作会异常。 @pxiphx891 broken pipe 毫无悬念 @zsh2517 传输大文件快,大量小文件非常慢的。但是压缩文件肯定是传输最快的。 @MacsedProtoss 的确没表达清楚。远端先解压,再传输原始文件,很慢;解压远端.zip 文件效率更高。 @zsh2517 当然能部分解压,但是不知道是不是所有文件都正确解压了。选“覆盖” 浪费时间,选“跳过” 会不会把解压一半的文件搞坏? @loveyu 用硬盘拷能解决单次问题,但是这里想解决以后重复出现的问题嘛 @kujou 的确需要升级网络和 NAS 了。但是希望软件能更 robust |
![]() |
30
wheat0r 9 天前
在 nas 端解压到某个目录,用 syncthing 把解压出来的目录同步过来
|
![]() |
31
mikewang 9 天前 via iPhone
@est #29 其实这不是解压软件的问题,而是 OS 抛出错误后,应用继续往上抛了而已。我来解释一下实现重试的难点。
假设应用通过 fopen()打开文件,fread()到一半出错了,这个时候如果重新 fopen(),会面临一个版本问题:我重新读的文件还是原来那个吗?有没有被修改过?这些应用都不能判断。 虽然这些是 corner case ,不过一旦遇到都是 bug ,可能造成数据丢失。最保险的做法就是将错误原样抛出去,fail-fast 思想。 这个应当是 OS 层面的责任,比如 macOS 在 SMB 连接断开时,应用尝试 read()并不会立即失败,而是阻塞住直到连接恢复(或者超时几分钟后失败),通过 SMB 协议确保读到的文件没有发生改变。我不太熟悉 Windows 上的机制,不过可以确定这个在应用层是没法处理的。 |
![]() |
34
ruanimal 9 天前
买个硬盘吧
|
![]() |
35
yulgang 9 天前
Linux: unrar
Windows: 7zip |
![]() |
36
est OP @mikewang
> 会面临一个版本问题:我重新读的文件还是原来那个吗?有没有被修改过?这些应用都不能判断。 可以给用户两个选择嘛: 1. 照原来的路径再试试 2. 放弃 这样可以节省大量时间。否则之前的解压都(几乎)白费力气了 |
37
n43635 9 天前
楼主是内网还是外网解压文件?内网如果这么断要考虑是不是用了 wifi 可以换成有线,如果是有线考虑是否是路由器或者 NAS 不稳定?
外网的话这么弄说实话挺反直觉的,而且多次解压重试说实话文件有没有损坏都不好说了 我觉得更好的方法有两种: 1 是升级存储,如果是笔记本换不了硬盘或者加硬盘也可以外挂移动硬盘,然后远程传 zip 包在移动硬盘或电脑硬盘解压进行配合 2 是远程解压后再传到本地,如果楼主顾虑小文件多网速慢可以试着多线程传文件,很多工具都支持比如 beyond compare ,速度一般也不会慢太多 |
![]() |
38
MoYi123 9 天前
看不懂你的问题,
如果是远程解压到远程本地, 用 nohup 开 unzip, 然后 ssh 关掉, 等会再连上去看结果就行. 如果是远程解压到本机, 你本机才 256G, 怎么解压? |
![]() |
40
est OP @n43635 远端 100G 传输到本地解压软件,解压软件写文件夹。本地不需要额外的 100G 存储空间,直接拿到解压完毕的文件夹。这样说清楚没。
如果在 NAS 上解压,那么 NAS 上需要付出额外的存储成本+传输效率不如.zip 直接读取快 如果在本地解压,本地 256G 无法存下 100G.zip 和解压完成的文件夹 但是理论上解压软件可以在读取 NAS 失败的时候一直重试,而不是粗暴的退出。 |
![]() |
41
MoYi123 9 天前
@est 这个东西还算简单, 最近我写安卓 TV 的 epub 浏览器里有还有这个
https://github.com/mmooyyii/malguem/blob/master/app/src/main/java/com/github/mmooyyii/malguem/LazyEpub.java 你让 ai 给你写一个就行了. 大致流程是 1. 解析 zip 内部的文件夹, 2. 遍历得到的文件夹, 确定每个文件对应的偏移量. 3. 按内部的压缩算法来解压单个文件, 如果有大文件, 要做断点续传, 因为可以得到 offset, 也比较简单. |
![]() |
42
Cusmate 9 天前
先 mount 远程文件夹到本地,写个循环脚本用解压工具 cli 解压,命令行带上对于同名文件如果大小一样就跳过,否者覆盖,中途异常退出就重新开始。
|
44
yanqiyu 9 天前
@mikewang #33 曾经的痛苦,给一台 VPS 改 wireguard 配置,配错了导致隧道断了,但是 systemd 不知道为什么就 D 在了这个 nfs 上面。
systemd 卡住了之后,新的 ssh 连接都进不去,已有的会话也什么都做不了,最后只能跑去 VPS 面板强制重启... |
45
psllll 9 天前
买个移动硬盘吧
|
47
henix 9 天前
unzip 有个 -u 选项: https://man.archlinux.org/man/unzip.1#u
> update existing files and create new ones if needed. > extracting (with query) files that are newer than those with the same name on disk, and in addition it extracts those files that do not already exist on disk. 相当于带断点续传的解压 但如果遇到网络报错的时候,有文件写入了一半的话最好把写入了一半的文件删除,然后再重试 unzip -u |
![]() |
48
kokutou 9 天前 via Android
7z 解压不是可以跳过相同的文件吗。。。
是个很大的单个大文件那就不行了 |
49
w568w 9 天前
感觉可以用 Python 、C++ 之类的自己写一个,zip 库都是内置的。
至于现成的解决方案,确实没听说过。关于「文件太大不好解压」这个问题,倒是可以用分卷来解决:我之前测试过,分卷之间是独立的,可以解压完一个、删除一个,反复给解压出的文件腾空间。 |
![]() |
50
1423 9 天前
盲猜你的 NAS TCP 拥塞没有用 bbr
可以换 bbr 试试 |
![]() |
51
LoliconInside 9 天前
CIFS 挂载参数加上 hard,timeout=xx ,hard 模式挂载会在网络中断时把文件系统调用阻塞住,然后把 timeout 提高,应该能应付了。
|
52
iceheart 8 天前 via Android
可能你需要的是 fuse-zip
|
![]() |
53
est OP |