Google Drive Rest API - 如何检查文件是否已更改

Question

是否有可靠的方法来检查文件是否在云端硬盘中更新/更改，而不是比较完整内容？

我已经为此苦苦挣扎了一段时间。这是我尝试过的两件事：

1.档案version号码

我将纯文本文件上传到 Google 云端硬盘（simple upload、update endpoint），并保存上传成功后返回的file metadata 中的version。

然后我偶尔轮询 Drive API (get endpoint) 以检查版本是否已更改。

问题在于，在上传文件后的一两秒内，版本又会变高。

文件内容没有变化。该文件尚未在其他任何地方打开、查看甚至下载。不过，版本号比上传后的版本号有所增加。

对于我的代码，此版本号更改表明云端硬盘中的远程文件已更改，因此它会下载新版本。每次！

2。 Changes 端点

作为替代方案，我尝试使用Changes api。

上传文件后，我使用changes.getStartPageToken 或changes.list 获得page token。

稍后我使用这个page token 来轮询 Changes API 的更改，并过滤已上传文件的 fileId 的更改。我在轮询更改时使用这些选项：

{
    "includeRemoved": false
    "restrictToMyDrive": true
    "spaces": "drive"
}

这里又是和版本号一样的问题。上传文件后立即返回的页面令牌会在一两秒内再次更改。新页面令牌显示上传的文件已更改。

同样，文件内容没有变化。它尚未在其他任何地方打开、更新、下载。它不与其他任何人共享。

然而，上传几秒钟后，文件重新出现在更改列表中。

因此，假设远程更改，本地代码会从 Drive 重新下载文件。

---

可能的解决方法

作为一个 hacky 钩子，我可以在文件上传后等待几秒钟，然后再获取新的文件版本/更改页面令牌。这可能会解决延迟版本增量问题。

但是，没有文档说明是什么导致了版本号（或 changes.list）的这种幻像变化。所以，我无法确定：

1. 在不丢失其他用户/应用可能进行的更改的情况下，等待多长时间才能安全地获得“已确定”的版本号？
2. 新的（延迟的）版本号是否会稳定，或者可能随时无缘无故再次更改？

---

是否有可靠的方法来检查文件是否在云端硬盘中更新/更改，而不是比较完整内容？

Answer 1

如果您的文件不是 Google Doc 文件（即二进制文件），您可以尝试使用 File resource object 的 md5Checksum 属性。您应该能够使用它来跟踪对二进制文件内容的更改。

您也可以使用Revisions API。

Revisions resource object 也有一个 md5Checksum 属性。

Answer 2

作为一种解决方法，使用 Drive Activity API 怎么样？我认为您的情况有几个答案。所以请认为这只是其中之一。

使用 Drive Activity API 时，可以检索有关目标文件的活动信息。比如从ActionDetail可以看到目标文件是否被编辑、重命名、删除等。

示例端点和请求正文如下。

端点：

POST https://driveactivity.googleapis.com/v2/activity:query?fields=activities%2CnextPageToken

请求正文：

{"itemName": "items/### fileId of target file ###"}

回应：

示例响应如下。你可以从这里看到信息。具有 fileId 和文件名的文件在时间戳处被编辑。

{
  "activities": [
    {
      "primaryActionDetail": {
        "edit": {}  <--- If the target file was edited, this property is added.
      },
      "actors": [
        {
          "user": {
            "knownUser": {
              "personName": "people/### userId who edited the target file ###",
              "isCurrentUser": true
            }
          }
        }
      ],
      "actions": [
        {
          "detail": {
            "edit": {}
          }
        }
      ],
      "targets": [
        {
          "driveItem": {
            "name": "items/### fileId of target file ###",
            "title": "### filename of target file ###",
            "file": {},
            "mimeType": "### mimeType of target file ###",
            "owner": {
              "user": {
                "knownUser": {
                  "personName": "people/### owner's userId ###",
                  "isCurrentUser": true
                }
              }
            }
          }
        }
      ],
      "timestamp": "2000-01-01T00:00:0.000Z"
    },
  ],
  "nextPageToken": "###"
}

注意：

• 当您在我的环境中使用此 API 时，请在 API 控制台中启用 Drive Activity API，并将https://www.googleapis.com/auth/drive.activity.readonly 包含在范围内。
• 虽然我在使用这个API的时候感觉反应很快，如果你用这个反应很慢，我很抱歉。

参考资料：

• Google Drive Activity API
• ActionDetail

如果这不是你想要的，我很抱歉。

Answer 3

您看到的是 Google Drive 文件系统的最终一致性功能。如果您考虑搜索，搜索索引的更新速度并不重要，重要的是它最终会更新并且阅读效率很高。 Google Drive 在相同的前提下工作。

云端硬盘会尽快确认您的更新。早在这些更新传播到您文件的所有全球副本之前。派生数据（例如时间戳，我想我记得 md5sums）也在更新“完成”后计算。

解决方案很大程度上取决于冗余同步对您的应用造成的问题。

• 几秒的延迟足以应对绝大多数幻影更新。
• 您可以切换到 v2 API 并使用 etags。
• 您可以使用自定义属性实现您自己的版本号。因此，每次同步时，都会增加自己的版本号。仅当应用程序版本号发生更改时，您才会向下同步。