一位同事（匿名以保护无辜者、罪犯以及意外恶魔召唤者落入的任何人）按照教程操作，其中包括将一些 gzip 文件与
zcat *gz | pigz --fast -c -p 16 > outfile.gz
因此，所涉及的文件都位于同一目录中，该目录位于 NTFS 格式的网络共享上（可从 Linux 和 Windows 计算机访问）。
他在一台 Ubuntu 机器上启动了该进程，然后去吃午饭，回来后发现文件大得难以置信，进程仍在运行。他终止了该进程，在他的 Windows 机器上的文件资源管理器中删除了该文件（或者他是这么认为的），并请我帮忙排除故障。当我们更合理地合并文件时（cat *gz > new_outfile.gz），我们注意到cat抱怨 outfile.gz 不存在。
嗯，我们刚刚删除了它，所以不应该，但ls在 Ubuntu 机器上，刷新 Windows 机器上的文件资源管理器后发现它又回来了。
我很好奇并试图看看发生了什么。
file outfile.gz告诉我这是一个“可写的常规文件；无读取权限”。
ls -l目录中显示文件权限为-rw-rw-rw-。
尝试查看文件的开头并zcat outfile.gz | head给出gzip: outfile.gz: no such file or directory。
在又几次不成功的尝试之后，我决定尝试在终端中删除该文件（sudo rm outfile.gz因为在 Windows 上以普通用户身份删除不起作用，我希望这样可以让它保留下来）。
并受到了欢迎rm: outfile.gz: no such file or directory。
我可以排除没有得到制表符完成的隐藏字符（如建议的另一个僵尸文件之谜) -ls -b显示不带任何转义序列的文件名。Windows 和 Ubuntu 计算机大多同意该文件是那里，除非我真正想用它做些什么。
查看了文件后，它看起来是另一次尝试的结果，并且其行为方式相同。
这里到底发生了什么？我们是否设法通过一种看似效率较低的文件合并方式召唤了 Filethulhu？（另一位同事显然成功地合并了文件，但输入和输出的目录是分开的。）我们究竟如何摆脱共享中这个 70+ GB 的可怕怪物？
答案1
因此，所涉及的文件都位于同一目录中，该目录位于 NTFS 格式的网络共享上（可从 Linux 和 Windows 计算机访问）。
这句话的背后有很多值得关注的部分：
samba或者smbfs（我敢打赌 Linux 应用程序会提供与 Windows 文件共享的网络连接）网络
Windows 文件名长度一般比较奇怪
Windows 和 Linux 在文件锁定等方面的差异以及
samba/smbfs或者必须翻译。
例如，如果出现网络问题，那么 Linux 和 Windows 端可能对情况有不同的看法，因此一方可能声称文件存在，而另一方则不存在。
那么，我们究竟该如何摆脱这个占据我们份额的 70+ GB 的可怕怪物呢？
- 停止
samba或smbfs在您的 Linux 机器上，重新启动 Windows 系统，在 Windows 上删除文件，在 Linux 上重新启动samba/ 。smbfs
为了弄清楚到底出了什么问题，我首先会查看 Linux 端的日志文件 - 可能在/var/log/samba- 其中应该有一个包含 Windows 系统的计算机名称或 IP 地址的文件，查看它可以发现线索。
答案2
删除这些文件的方法其实很简单：这些文件是无法删除的，因为 CIFS 内核驱动程序对它们进行了锁定，只需重新启动 Linux 机器就可以解决这个问题。
（虽然这不是它无法删除的原因，但是 @KamilMaciorowski 很好地解释了我们一开始是如何陷入这种情况的：在管道的第一部分被扩展outfile.gz之前被创建* gz；目录中的一些其他文件首先被处理，然后不断增长的数据outfile.gz被输入到自身中，直到进程被终止。）