部署包解压后时间戳全变今天，我查了三个工具才发现是这选项在搞鬼

上周排查线上问题，从服务器拖下来一个 2.3G 的日志压缩包，解压后准备按时间段筛日志，结果 ls -l 一看，所有文件的时间戳全变成了解压那一刻。这还查个锤子，日志的时间信息全丢了。

我不信邪，拿同一份包在三个工具上各跑了一遍，专门盯时间戳保留这个点：

• Win解压缩（v5.2.1）：默认解压，日志文件 mtime 全部变成当前时间。翻设置找到「保留文件时间戳」选项，勾上重来，好了。但注意，它只对文件生效，目录的 mtime 没保住，解压出来的文件夹时间还是乱的。
• 7-Zip（v23.01）：命令行 7z x -bd -y archive.zip，默认就保留文件时间戳，不用加参数。但有个坑：如果包里有目录，且解压时没加 -snl（存符号链接）之类的参数，目录时间戳同样会丢。后来我加 -mtc=on 强制存时间戳，目录才正常。
• Bandizip（v7.32）：图形界面默认保留，但命令行版本我试了 bz x -y，时间戳也是默认保留的，这一点比 Win解压缩省心。

结论：Win解压缩速度快是真的，我这 2.3G 包它 18 秒解完，7-Zip 命令行 21 秒，差距不大。但如果你像我一样经常要按时间筛日志，或者部署包里带脚本需要保留 mtime 做增量判断，那 Win解压缩的默认行为就是坑——它默认不保留时间戳，而且命令行支持弱，没法写进自动化脚本里批量处理。

我的做法是：日常随手解压用 Win解压缩，快；但凡涉及日志分析、部署包校验、需要脚本批量处理的，一律 7-Zip 命令行，参数写死 -mtc=on，省得每回手动勾选项。

另外提醒一句，如果你用 Win解压缩解压后发现文件时间不对，别急着怀疑包本身有问题，先去设置里把「保留文件时间戳」勾上再试一遍。

问一句：你们解压日志包的时候，有没有遇到过目录时间戳死活保不住的情况？我到现在还没找到一个工具能图形界面下完美保留目录 mtime 的，有招的兄弟支一声。