files.list() 在 parent 中搜索 q='FOLDER_ID' 时返回一个不完整的列表答案

【问题标题】：files.list() returns an incomplete list when searching for q='FOLDER_ID' in parentfiles.list() 在 parent 中搜索 q='FOLDER_ID' 时返回一个不完整的列表
【发布时间】：2023-03-14 21:06:01
【问题描述】：

我正在尝试收集作为给定文件夹后代的所有文件和文件夹。

为此，我使用带有q="'FOLDER_ID' in parent" and trashed=false 的file.list()，其中FOLDER_ID 是我感兴趣的文件夹的ID。在处理结果时，我会跟踪从该请求返回的所有文件夹，并然后使用 q 参数中的新文件夹重复 files.list() 调用。我使用or 将多个文件夹合并到一个请求中，并继续重复此操作，直到没有返回新文件夹。

例子：

初始请求：q="('FOLDER_ID' in parent) and trashed=false"
所有后续请求：q="('FOLDER_ID_1' in parent or 'FOLDER_ID_2' in parent or 'FOLDER_ID_3' in parent ...) and trashed=false"

（有关如何创建查询的更多信息，请参阅Drive REST API - Search for Files）

有时这会返回它应该返回的所有文件夹，有时会忽略一些文件夹。如果我删除 q 参数，则不会发生这种情况，因为每个文件和文件夹都返回，没有丢失。

经过一些测试/反复试验，我发现如果我没有收到我应该收到的所有文件夹，发送一个没有q 的请求似乎可以“解决”问题。下次我运行我的应用程序并使用 q 时，所有正确的文件夹都会返回。

其他信息：

不是权限问题，我用的是drive.readonly
这不是pageSize 问题，因为我为此尝试了不同的值并得到了不同的结果。
这不是pageToken 问题，因为我确保在给定nextPageToken 存在时再次发送请求。
我正在一个文件夹中运行此程序，该文件夹中包含略低于 4,000 个后代文件夹和略低于 25,000 个后代文件。

我觉得这一定是与在单个请求中使用q 参数中的多个文件夹有关的错误，考虑到我可以执行完全相同的过程并且会看似随机地得到不同的结果。

【问题讨论】：

标签： google-drive-api

【解决方案1】：

我建议你放弃你所采取的方法。对云端硬盘进行如此多的调用将需要很长时间，并且可能会给您带来配额问题。

在一个查询中简单地获取所有文件夹，然后在内存中构建您感兴趣的文件夹 ID 的层次结构，这要简单得多。然后运行第二组查询来获取这些父级的文件.

或者，如果这些文件是由应用程序创建的，请将它们全部设为您可以查询的通用虚拟父文件夹的子文件夹。

【讨论】：

感谢您的建议。首先获取文件夹似乎是一个合理的选择。但是，根据 Google 的 Drive API 文档和指南，我认为这没有必要，而且我认为这并不简单，因为在这两种情况下我都需要构建内存层次结构。另外，不管你信不信，完成这个过程并不需要很长时间，通常在 1 分钟左右，
试试看。你会喜欢的。另一个技巧是更新每个文件夹以使其成为虚拟父级的直接后代。请注意，云端硬盘不强制执行层次结构，因此您的递归应防止出现一组循环关系。
我会测试一下。我确实认为虚拟文件夹的想法听起来不错。但在我的情况下，文件夹不是由应用程序创建的，所以这并不可行。我还试图让这个脚本成为一个非常通用的脚本，可以在任何情况下工作，所以我宁愿远离它。
在测试了查询所有文件夹的建议，然后查询相关文件夹中的所有文件之后，我这样做没有意义。完成此过程需要相同的时间，并且实施起来并不简单。获取根文件夹下的所有文件夹和文件当然是一种可行的方法，但这并不是更好。问题在于 Google。

【解决方案2】：

我在查找给定用户拥有的所有文件时发现了类似的问题，例如：

'example.user@company.com' in owners and trashed=false

我有大约 5000 个文件，通常我可以通过分页遍历所有文件。然而，有些日子（比如今天）我只得到

在我看来，谷歌驱动器服务器上存在某种缓存问题。

【讨论】：

很有趣，所以我想就像您所说的那样，它不仅仅与一种查询相关。这绝对是谷歌的问题。