在移至永久存储之前将文件上传到 /tmp 的优点是什么？

Question

在构建处理文件上传的功能时，编程的常见趋势似乎是首先将文件上传到临时目录/文件夹（例如 Linux 上的 /tmp）。文件完成后，将其从临时目录中移出，并放置到指定目录中进行存储。某些编程/脚本语言默认将正在进行的上传放置在 /tmp 中，而其他语言则不然，但通常的做法是显式将 /tmp 设置为占位符目录，直到上传完成，此时它会被移动到单独的目录。

在将文件移动到另一个分区/目录进行长期存储之前，使用临时“保留”目录来上传内容有什么好处？

我工作的环境中（内部）网络存储通过 NFS 安装到虚拟机，以持久存储大量数据（TB）。随着技术的进步，我们能够更快、更大量地获取数据。几年前，这是一次简单的 HTTP 上传一个文件（文件大小相对较小，兆字节？），然后我们转向 Flash 上传。现在我们可以拖放上传，甚至可以在某些浏览器中上传千兆字节的文件/文件夹结构。现在已经到了这样的地步：如果一个用户确实想一次上传足够多的文件，那么他们很容易就会超出为 /tmp 预留的分区。除了通过 NFS 安装的网络延迟之外，扩展 /tmp 与直接将其发送到文件服务器相比有何优势？由于技术允许我们获取十年前无法想象的大量数据，这种传统（现在是糟糕的）做法是否已经过时了？

Answer 1

1. 如果指定的存储目录是网络存储，是否是为了性能？
   • 是的，可能是这样，尽管通常不是这样。实际上传的性能很少是代码的主要性能问题。
2. Linux 是否会定期扫描 /tmp 目录以删除旧文件，从而使开发人员/管理员不必在其他地方对此进行解释？
   • 是的，通常是这样。这还涵盖了上传管理器进程崩溃并留下部分文件的情况，否则这些文件不会被清理。
3. 难道就因为这样吗？
   • 是的。 :-)
4. 如果有机会简单地将文件写入最终将存储在其中的目录（例如使用node.js 的 fs 模块），我应该这样做吗？或者这是一个禁忌吗？
   • 使用临时暂存目录以及将其放置在与目标目录相同的文件系统上有充分的理由。许多应用程序将此目录放在与最终目标目录相同的文件树中，因此最终的“移动”操作将几乎是瞬时的（并且可能是原子的）。因此，您会经常看到类似/var/spool/myapp/tmp和 的内容/var/spool/myapp/data。但随后应用程序通常会添加一个cron任务来清理.../tmp.

Answer 2

这实际上取决于系统上还有什么以及它们的使用方式。

在某些系统上，/tmp通常用于系统文件或交换空间。如果你在 Solaris 上填满/tmp，坏事发生（以及相关轶事）。在这种情况下，如果有人上传填满此卷的文件，则可能会使您的系统崩溃。其他可能发生的情况是某些应用程序将无法写入自己的临时文件。

在过去，你可以合理地相信人们不会愚蠢（至少在九月之外），而且恶意也相当低。今天……那是一个不同的故事。

这优势写入的/tmp原因是它被保证是机器上的本地文件系统，存在并且被巡逻（脚本将自动删除旧文件）。系统需要的启动/tmp和快速访问它对于系统的合理性能是必要的。因此，您想在某处快速写入文件然后将其移走吗？把它放进去/tmp。

考虑到/tmp满载时会发生不好的事情，人们应该考虑提供相同优势的其他替代方案 - 例如创建一个安装的分区来上传文件，当满载时不会使机器崩溃。

另一个考虑因素是“快”位。自古以来，驱动器变得越来越快。速度快了很多 - 一个漂亮的 SSD 可以摧毁当时的任何东西......但是你知道吗？真的需要 SSD 来写入上传文件吗？不仅潜水变得更快，而且网络也变得更快。将上传文件写入网络存储区域可以在单点上提供帮助，您可以让多个系统将其文件上传到一个中心点，然后其他进程可以负责扫描它们并将它们移动到正确的位置。

所以...总结一下：

• 以前就有优势
  • 比网络更快，永远存在
• 可能会导致问题
• 昔日的日子已不复存在
  • 驱动器和网络速度更快
  • 人们很愚蠢，攻击者更多

所以，我会说不......不要再写信/tmp作为默认答案。请咨询您的系统管理员，了解适合其磁盘使用策略的写入位置，并考虑将它们写入完全脱离本地系统的某个位置。

Answer 3

/tmp只是一个放置文件的方便位置，并且您可以相当有信心地在某个地方将被清理（例如，如果网络应用程序未能执行此操作）。所以这是一个合理的默认值。

如果您确实可以选择指定自己的上传文件的路径，则有充分的理由将其设置为与最终目的地相同的装载路径，因为这样您就可以使用原子重命名将其放入最终目标地方。 （如果是交叉安装，则需要复制一份）。

我不会将其上传到最终目的地，因为（例如）如果上传在中间中止，您可能会在那里留下部分文件。或者，如果您的脚本失败，您可能会留下一个数据库未引用的孤立文件。

顺便说一句：请记住，客户端提供的文件名是不受信任的数据。恶意用户可以轻松地向您提供文件名../../../something，如果您不小心，您可能会写入您不希望写入的内容。