如何处理文件服务器竞争条件?

How to handle file server race conditions?

我正在开发一个应用程序,它每 1 分钟轮询一次网络文件服务器 (cifs) 上的文件夹以获取计划的 cron 作业上的新文件。

当它看到一个新文件时,它会暂时将其复制到本地文件系统,然后对该文件执行各种操作,然后将其从本地和网络文件系统中删除。

我担心我的应用可能会在有人向网络文件夹添加文件的同时轮询网络文件夹。这些文件非常小 (1kb),因此当我轮询文件夹时文件仍在复制的情况应该非常罕见,但它可能会发生。

我的问题是,这是合理的担忧吗?如果是,我应该如何处理?

这是我解决问题的方法。

请注意,我在工作流程的多个方面都遇到过这个问题。第一个是我必须用我的应用程序监视目录中的新文件并确保它们已完成传输等。第二个是我必须将文件上传到另一个软件正在监视的目录 a) 我没有控制,b) 非常陈旧,本身不做任何验证。

解决第一个问题:

在我预定的工作中,我扫描了所有文件的目录,然后为每个文件生成了一个 md5 哈希值,并将其与文件路径一起保存到数据库中的 table。

下一次我预定的作业 运行s(1 分钟后),我从数据库中取出所有行(文件路径和哈希),检查文件是否仍然存在,然后生成一个再次对文件进行 md5 哈希。如果文件存在且散列相同,我将对文件进行处理(并将其从目录中删除)。如果这两个文件中的一个失败,我只需跳到循环中的下一个文件。

处理完所有文件后,我运行对索引文件的table进行分类,然后重新索引所有文件,将它们重新保存到数据库中。一分钟后,我的工作再次开始使用索引中的文件。

通过这种方式,我永远不会处理我尚未从上一份工作中编制索引的文件 运行。我相信可以安全地假设,如果文件哈希值在 1 分钟内没有更改,那么文件已完成传输,我可以使用它。

解决第二个问题:

为了确保其他软件不会消耗我可能正在上传的文件,我只是在服务器上创建了另一个软件未监控的目录,并将文件上传到那里。文件传输完成后,我发出移动命令将文件移动到受监控的目录,因为移动是文件系统上的原子操作,因此不会出现竞争条件。