监视文件更改时打开太多文件

Question

我正在为iPad开发基于文档浏览器的应用程序。我一直在使用SKQueue监视文件的更改，以确保当用户在文档浏览器中执行操作时它们的元数据保持最新。启动监视的代码：

    // Set up the queue
    let delegate = self
    queue = SKQueue(delegate: delegate)!
    // Remove all existing paths
    queue?.removeAllPaths()

    // Get the list of PDF URLs using a function that enumerates a folder's contents
    let pdfFiles = getFolderContents(rootFolder: myDocumentsFolder, extensionWanted: "pdf")
    for pdfFilePath in pdfFiles.filePaths {
        queue?.addPath(pdfFilePath.path)
    }
    for pdfFolderPath in pdfFiles.folderPaths {
        queue?.addPath(pdfFolderPath.path)
    }

我开发了自己的逻辑来响应来自此队列的通知，但是在应用程序运行时，我没有从队列中删除任何项目。

问题-似乎当监视的项目数超过200（文件和文件夹）时，系统撞墙并且控制台报告错误24：打开太多文件。之后，将无法执行任何文件的读取/写入。

根据我从搜索中收集到的信息，似乎iOS和iPadOS不允许同时访问超过256个文件描述符，这意味着GCD监视文件更改的方法将遭受相同的限制。

是否有不受此限制的监视文件更改的方法？还有其他建议吗？

Answer 1

经过大量的研究和实验，我终于可以证实，对于MacOS，iOS和iPadOS，打开文件描述符的默认最大允许数目是256。在MacOS中可以轻松更改此设置-请参见文章here。但是，iOS和iPadOS本质上更加封闭，在这些平台上没有可靠的方法来更改此限制。

因此，良好做法是：

1. [避免避免设计会调用太多文件描述符的应用。
2. 监控目录，而不是单个文件。使用大多数可用于监视文件系统的工具，您会收到有关受监视目录中任何文件更改的通知。通过枚举文件夹并将其新状态与保存状态进行比较，只需从那里实施逻辑即可。您可以在此SO thread的前两个答案中找到合适的代码。

注：我建议枚举而不是其他获取文件系统状态的方法，因为其他方法往往会在模拟器和实际设备之间产生不兼容的结果（对符号链接解析的不同处理。）

3. 确保可以查询您选择的监视文件系统的方法以了解正在监视的项目数，如果用户接近设置的限制，则发出警报。请记住，这256个打开的文件还必须包括该应用程序使用的所有文件，包括应用程序捆绑包中的文件和实际使用的文件。因此，请注意安全性。

就我而言，我的应用程序使用UIDocumentBrowserViewController，或者换句话说-Apple自己的Files应用程序，以允许用户管理其文件。我必须使元数据与文件系统状态保持最新，并且无法控制用户的文件管理习惯。使事情复杂化的是，“文件”应用程序本身可用于修改该应用程序的文件系统-当我的应用程序未激活时。

因此，我做了两件事：

1. 我将来自App Delegate的applicationDidEnterBackground和applicationWillTerminate方法的文件系统的详细状态保存到Application Support中的json文件中，并在应用程序启动时将其与文件系统的新枚举进行比较-并提醒用户任何不匹配，建议下次使用该应用程序自己的文件浏览器。
2. 我创建了自己的快速包，名为SFSMonitor，用于监视文件系统。它基于非常方便的SKQueue（我强烈建议），但它不是监视kevent，而是使用了Dispatch Sources-Apple提倡的一种更现代的方法。它与Apple自己的目录监视器（您可以在其中找到here的目录监视器）相似，但是它无需监视一个目录，而是允许您创建和管理它们的整个队列。此类允许您设置最大数量的受监视文件描述符，并在达到该限制时收到通知。