使用Ubuntu 22.04
我有一个包含一堆文件的文件夹，我想更改文件扩展名，所以我使用了：
rename 's/\.zip$/\.cbz/' *.zip
该命令完成后没有抛出任何错误，但我发现大约 2/3 的文件丢失了。我认为这与某些包含括号或引号的文件的名称有关，但我知道一些丢失的文件的名称非常简单（comic5.zip），并且我发现每个名称以括号开头的文件现在都丢失了。
我尝试使用 photorec 来恢复这些文件，但它找不到其中一个。
现在文件夹大小小了很多，这似乎表明它们已被删除，但如果是这样的话，我会认为 photorec 能够恢复至少其中一些。仅使用我的文件资源管理器，运行该命令之前该文件夹约为 120GB，运行后约为 40GB。不幸的是，我没有在命令之前查看文件的实际数量，但我也可以通过滚动来判断文件少得多。
有谁知道这些文件发生了什么以及是否可以恢复？
$ rename -V
/usr/bin/rename using File::Rename version 1.30, File::Rename::Options version 1.10
更新：
结果我忘记更改 photorec 中之前的一些设置，我再次运行它，它确实找到了丢失的文件，很确定现在所有文件都已恢复。我认为这证实了这些文件实际上已被删除。仍然不确定它是如何发生的，但我认为斯蒂芬的解释是最有可能的。
无论如何，感谢您的帮助。
答案1
考虑您运行的命令：
rename 's/\.zip$/\.cbz/' *.zip
这会将当前目录中与 glob 模式匹配的每个文件或目录名称的最后四个字符从 更改为。就这样。它使用 Perl 替换表达式来执行此重命名。*.zip.zip.cbz
此外，至少在我的系统上，rename将拒绝重命名目标名称已存在的项目（文件）：
touch a.zip a.zap
rename 's/\.zip$/.zap/' *.zip
a.zip not renamed: a.zap already exists
我发现大约 2/3 的文件丢失了
在您描述的情况下，我看不到任何合理的+会导致文件（或目录等）消失的情况。也许还有另一个命令，例如mv，在覆盖之前不执行健全性检查。检查你的history，看看它显示了什么
* 实际上，它会重命名任何类型的项目，无论是常规文件、目录、设备、管道……但仅限于符合我描述的条件的情况
+ 以破折号 ( -) 或双破折号 ( --) 开头的文件总是有问题的。这里也是如此，除非您通过使用独立的分隔命令参数和文件参数--或使用修改后的./name格式而不是普通格式来保护文件模式name。例如mv -- -a dasha重命名-a为dash.
答案2
$ touch {comic5,{a..d}}.zip './--e=BEGIN{unlink for <c*>}#.zip'
$ ls
a.zip b.zip comic5.zip c.zip d.zip '--e=BEGIN{unlink for <c*>}#.zip'
$ rename 's/\.zip$/\.cbz/' *.zip
$ ls
a.zip b.zip d.zip '--e=BEGIN{unlink for <c*>}#.zip'
哎呀！所有名称以 开头的文件c都已被删除。
对于File::Rename的实施rename，此类问题是固定在1.99（根据我的要求）但 Ubuntu 22.04 附带版本 1.30。
在这里，你会想要：
rename 's/\.zip\z/\.cbz/' ./*.zip
使用该./前缀可防止 1 将任何 zip 文件名作为选项rename。
或者，对于 的特定实现rename，通过其标准输入而不是参数传递文件列表：
printf '%s\0' *.zip | rename -0 's/\.zip/\.cbz/'
与 shell 一起，其中printf内置（大多数）也适用于Argument list too long限制。
或者使用zsh'szmv代替，它不存在此类问题，有一些额外的保护措施并且通常更易于使用²：
autoload -Uz zmv
zmv '(*).zip' '$1.cbz'
现在看来，这种事情不太可能是偶然发生的。如果发生这种情况，某人就会在知道您将运行此类命令的情况下，在当前目录中植入一个名称相似的恶意文件。
如果恶意代码确实存在unlink()，或者由于rename()替换文件而删除了文件，那么您可能会使用一些文件系统取消删除/恢复方法。如果它执行了与shred/相同的操作wipe，或者像勒索软件一样在将文件移动到其他地方之前对内容进行了加密，那么您最好的选择是从备份中恢复。
在没有恶意文件名的情况下，rename通常不会丢失数据，因为它会在重命名之前检查目标文件是否存在。如果这些符号链接的目标无法访问，您可能会丢失符号链接文件rename用途-e <the-target>对于无法像实用程序那样解析的符号链接，这将返回-efalse [：
$ touch a.zip
$ ln -s /x a.bcz
$ ls -n
total 4
lrwxrwxrwx 1 1000 1000 2 Dec 22 08:39 a.bcz -> /x
-rw-r--r-- 1 1000 1000 0 Dec 22 08:39 a.zip
$ rename -v 's/\.zip$/\.bcz/' *.zip
a.zip renamed as a.bcz
$ ls -n
total 0
-rw-r--r-- 1 1000 1000 0 Dec 22 08:39 a.bcz
哎呀！那个（损坏的）a.bcz符号链接消失了。
但符号链接在磁盘上占用的空间非常小，因此这无法解释您所遭受的 120GiB 损失中的 80%。
和克里斯一样，我怀疑你的问题出在其他地方。您的文件甚至可能仍然存在，只是不在您认为它们应该在的目录中。尝试一下sudo find / -iname 'comic5.zip' -o -iname 'comic5.cbz'
¹ 另请注意，您通常希望在正则\z表达式$中使用 in 来匹配除线as$匹配主题结尾处（您在这里想要的）或主题结尾处换行符之前（您不想要的，但在这种特殊情况下，主题以换行符结尾，.zip而不是换行符，所以不会不是问题）。
² 即使通常速度较慢，因为它为mv每个文件调用一个。虽然你可以运行zmodload zsh/files以获得内置的mv.