我在Android上运行了一个应用，并使用Drive SDK java API将XML格式的内部数据库副本发送到链接的Google云端硬盘帐户。要更新文件，请执行以下操作。首先，文件obj。从给定的已知文件ID（与驻留在Google云端硬盘中的.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是一个非null byte []对象。
直到2014年4月22日，美国东部时间凌晨5点，此代码剪辑完美且无情地工作，并更新了驻留在Google云端硬盘中的XML文件，其中包含应用程序使用的本地SQLITE数据库的副本，但在人类中 - 可读和HTML可解析的格式。
在我们所有测试站点上同时在这个日期和时间发生的事情，无论是加拿大方还是美方方面如下：文件的修改时间戳保持正确更新为currentTimeMillis（），但是二进制内容该文件保持与上次有效更新相同（即在2014-04-22 05：00.00 EST的几分钟内）。
我们解决此问题的唯一方法是通过API完全删除与该XML文件对应的文件ID，或者通过将文件转储到垃圾箱中手动删除，然后清除垃圾箱。请注意，如果文件仅移动到废纸篓，则同样的问题会不断出现。这不是因为我们修改了垃圾箱中的文件（或者看起来如此），因为我们尝试多次重启应用程序，并且在重启时（以及任何Google Drive失败后），应用程序进入＆＃ 34;慢速扫描模式＆＃34;，并通过查询相关文件夹中所有文件的Google云端硬盘重建整个文件层次结构，并使用以下Q字符串标记：
trashed = false and hidden = false
如果情况确实如此，那么我的猜测是我们不会在包含XML文件的主文件夹中看到正在更新的时间戳，我们确实看到了。此外，在没有手动丢弃垃圾的情况下，我们确实看到文件时间戳按预期更新为currentTimeMillis（），但其内容保持过时，直到我们通过删除完整文件来清理驱动器。
现在，我们正在为此进行损害控制，但如果这可以很容易地解决服务器端而不是我们不得不在任何地方手动推送客户端补丁那么会很好......如果有根本原因对此，我们的任何补丁都不会解决这个问题，只能推迟不可避免的事情。
有什么想法吗？