我有一个在 Android 上运行的应用程序，并使用 Drive SDK java API 将 XML 格式的内部数据库副本发送到链接的 Google Drive 帐户中。要更新文件，请执行以下操作。首先，一个文件 obj.从给定的已知文件 ID 中获取（与驻留在 Google Drive 中的 .xml 相对应的文件 ID）：
final File tmpfile = driveService.files().get(mapperID).execute();
tmpfile.setTitle(XML_FILENAME);
tmpfile.setDescription(XML_FILEDESCRIPTION);
tmpfile.setModifiedByMeDate(new DateTime(System.currentTimeMillis()));
tmpfile.setMimeType(XML_MIMETYPE);
//Note: fileBuilder.srcFile contains a byte array of the binary content to be pushed to Drive
mediaContent = new ByteArrayContent(XML_MIMETYPE, fileBuilder.srcFile);
File tmpResFile = driveService.files().update(mapperID,tmpfile, mediaContent).execute();
...其中mapperID 是从HashMap 对象获取的ID 字符串，该对象包含Google Drive 内所有相关文件ID 的列表，fileBuilder.srcFile 是一个非空byte[] 对象。
直到美国东部时间 2014 年 4 月 22 日凌晨 5 点，这段代码一直完美无情地工作，并更新了 Google Drive 中的 XML 文件，其中包含应用程序使用的本地 SQLITE 数据库的副本，但采用人类可读的格式，和 HTML 可解析的格式。
在这个日期和时间，我们所有的测试站点（无论是加拿大端还是美国端）同时发生的情况如下：文件的修改时间戳不断正确更新为 currentTimeMillis()，但文件的二进制内容与上次有效更新相同（即在 2014 年 4 月 22 日 05:00.00 EST 的几分钟内）。
解决此问题的唯一方法是通过 API 完全删除与该 XML 文件对应的文件 ID，或者手动将文件转储到垃圾箱中，然后清除垃圾箱。请注意，如果文件只是移至垃圾箱，则同样的问题会不断出现。这不可能是因为我们修改了垃圾箱中的文件（或者看起来如此），因为我们尝试多次重新启动应用程序，并且在重新启动时（以及在任何 Google Drive 故障之后），应用程序进入“缓慢”状态扫描模式”，并通过在 Google Drive 中查询相关文件夹中的所有文件来重建整个文件层次结构，并使用以下 Q 字符串标志：
trashed = false and hidden = false
如果情况确实如此，那么我的猜测是，我们不会看到包含 XML 文件的主文件夹中的时间戳被更新，而我们确实看到了这一点。此外，在不手动将任何内容扔进垃圾箱的情况下，我们确实看到文件时间戳按预期更新为 currentTimeMillis()，但其内容仍然过时，直到我们通过完整文件删除来清理 Drive。
现在，我们正在对此进行损害控制，但如果这是可以在服务器端轻松解决的问题，而不是我们必须手动在各处推送客户端补丁，那就太好了……如果有根本原因，我们这边的任何补丁都无法解决这个问题，只会推迟不可避免的事情。
有任何想法吗？
