Google File Stream 非常可怕的 Bug，随机添加已存在的数据到另一个文件，大家小心

[8e47e42]

Google File Stream 老用户了，最近更新了 30.1 版本以后突然经常出现 PDF/AI 文件编辑过以后随机打不开的情况，像这样：


直到有一天客户和我说，我们发过去的 PDF 文件是损坏的，但是通过某些 PDF 阅读器能看得到一张别人的合同的一部分，这可真的把我们吓得不轻，赶紧抽样了那些损坏的 PDF 文件做了比对，发现：


这些 PDF 文件损坏的原因是一样的，是这个文件随机包含了一部分额外的数据，因此尺寸、文件大小都增加了很多。


于是我们提取了这部分数据，发现居然是一个多媒体文件，而这个文件正是另一个 Google File Stream 里已经存在的 PDF 当中的一张图。也就是说，GFS 被更新版本以后的这个 bug 会随机的把已经存在你 GFS 里面的文件的一部分随机的插入到你最近更改的文件当中去，这个随机部分可以是你硬盘里的小姐姐，也可以是机密合同。细思极恐。

联系了 G Suite Business 的技术支持，只说有可能是服务器问题，没有任何实质性帮助，连滚回的安装包居然都提供不出来。

各位 G Suite 的 Google File Stream 用户发邮件之前一定记得查验一下自己发的文件，这种诡异的 Bug 实在是坑爹啊！！！

复现步骤：
Win10 最新版+GFS+最新版 Adobe 系列编辑器，干净系统
PDF 里面加上若干矢量图形（如稍微复杂一点的自定义 PDF 印章）。数量一多以后保存，同步图标闪一下以后，就会触发这个 BUG
雷同的 AI 文件如果加了一个复杂的元素（>原来文件的大小尺寸很多的修改）也会有比较大几率触发 bug
有点随机，但是还是有规律的。

#更新一个更可怕的错误

就在刚才，我和 G Suite Support 邮件跟进的时候发现我的 attachment 缩略图变了，出于好奇我点开来看了一下，在 Gmail 当中的问题附件居然变成了一份别的公司的完整合同，我可以在 gmail 中正常浏览，但是不能下载。G 家这是要完啊

我们有帮 Google 做 log 分析（对大家没看错 9102 年谷人希现在都没有处理完这个 critical bug，甚至拖了这么多天连 log 分析结果都没有给），基本应验你说的 2，Google Drive File Stream 的虚拟驱动有问题，导致 actually 和 expected 的不同，从而在写入的时候导致错误，具体体现为报错日志和出问题文件的写入时间高度一致，服务器上是不是有更进一步的问题尚不明确，但是 local 的 GFS 是真的有问题，建议大家别用了。

更可怕的是我们做 research 的时候发现了这个： https://www.greyhathacker.net/?p=1041
而这种级别的 bug，Google 根本就没有发任何通知。

给大家讲个笑话，Google Drive File Stream 是企业级应用呢

[loveour]

不会吧，这个是太严重的 BUG 啊！如果有这种问题，那根本就没办法相信 GFS 了好吧。。

[loveour]

有没有什么复现步骤？

[8e47e42]

@loveour 直到真的自己去比对了损坏的文件才敢相信这个错误，疑似和更新中
“ Drive File Stream now uses cached content more efficiently, resulting in faster downloads that use less network bandwidth.” 有关。

[loveour]

@8e47e42 #3 确实，这样的错误也太低级太严重了。基础服务搞不好，什么优化都是扯。不过我去搜了下“ Google File Stream data corrupted ”，貌似不少人遇到过数据损坏，然后 Google Adviser 就都建议卸载删掉缓存重新安装。。。

[8e47e42]

复现步骤：
Win10 最新版+GFS+最新版 Adobe 系列编辑器，干净系统
PDF 里面加上若干矢量图形（如稍微复杂一点的自定义 PDF 印章）。数量一多以后保存，同步图标闪一下以后，就会触发这个 BUG，而如果只是简单修改以后保存不会触发这个 bug

[rocbomb]

随着硅谷印度人越来越多,软件发展也越来越迅速

[xiaolanger]

@rocbomb #6 我一直以为关于印度人的代码质量，是个段子，现在来看，真的影响这么大？

[lastpass]

擦，这种低级的 bug 太过可怕了。
谷狗写出代码?简直不敢相信。

[ldm0]

这种 bug 是怎么做到过测试的。。。
这两年软件质量很绝望啊。。iOS11，Win10 1809, 现在 Google 家也出现这种问题了吗。。

[8e47e42]

我比较相信是服务器的问题，我和 G Suite Support 邮件跟进的时候发现我的 attachment 缩略图变了，出于好奇我点开来看了一下，在 Gmail 当中的问题附件居然变成了一份别的公司的完整合同，我可以在 gmail 中正常浏览，但是不能下载。

[runking]

https://www.v2ex.com/t/547494

对比着这个看下

2 年经验的产品都不会设计出有如此严重权限错误的产品

[8e47e42]

@runking
真的，我觉得稍微好一点的大专学生应该都挺难犯这种水平都错误的

到目前我们公司没有得到任何有效的支持或帮助，准备周一去投诉了

[yexm0]

发去国外的论坛搞大它吧

[gqfBzoLVY3Wl4Tng]

所以 IT 界都是印度人了嘛

[billytom]

@8e47e42 建议 Reddit 投诉

[mmdsun]

学百度云的吧。文件都是共享的 hash 匹配，只存一份。

其他的人都是超链接。

估计是 hash 冲突了

[8e47e42]

@billytom
我们应该会去这边消费者仲裁会让他们出面跟进，全部复现我们录了复现视频，截至目前都没有修复。
最令人惊讶的是，Google 居然没有回，相比之下 M$一小时内响应的企业客服支持不知道高到哪里去了

[geelaw]

学习了一下 Google File Stream 是什么……你是说 Drive File Stream 吗？（也就是 Windows 10 最近开放的 storage provider 接口提供的 on-demand 文件同步 API。）

如果是的话那真的是💊了，因为 Drive File Stream 是 G Suite （企业产品）专用，居然是这样的 support 水平……

[8e47e42]

@geelaw
对没错就是它，神奇的是，纯企业产品居然这个 testing 水准。。

[wangsongyan]

太恐怖了

[ladypxy]

@ldm0 你为什么会 产生 google 代码比其他家好的错觉。。google 的代码质量一直是几家里最差的，你看看 android, chrome 这玩意就知道了，bug 无穷无尽，无非就是靠的快速更新来取胜。。只不过 google 一直没有像样的产品进入企业市场，和大众接触的少罢了

[jememouse]

这也太恐怖了。我一百多 g 的资料，现在这问题是出在客户端还是服务器里面？

[burning]

用过一段时间 Google Drive，很不理想，转 Dropbox 了。

[lizhuoli]

关注

[NimaQu]

图炸了楼主

[visualer]

建议直接转 reddit

[JerryCha]

卧槽？得立马停用了。好在我 Google Drive 目前只是拿来做文件跨设备同步为主。

[Da11as]

https://www.v2ex.com/amp/t/549665

[will0404]

关注

[sobigfish]

建议转 reddit 时不要提印度人（不然会被当成种族歧视而。。。）

[msg7086]

File Stream 不建议大量使用……以前挂载 GDrive 曾经搞死过 Windows 内核……

[xiechengen]

可以联系我吗 我帮你开个 ticket

[8e47e42]

@xiechengen 求联系方式

[8e47e42]

@JerryCha
@msg7086
比较惨。。我们是用做 production 的，一下要切到别的网盘服务太耗时间了

不得不说最近 Google 真的不行，这个月早先时候还 Gmail 还在工作日 down 了几个小时

[HuasLeung]

关注

[xiechengen]

@8e47e42 看我简介 或者你留个邮箱啥的

[Trumeet]

话说用什么工具看的文件对比？

[8e47e42]

@Trumeet 图中是 WinMerge 方便截图了，当然也可以用别的

[Trumeet]

@8e47e42 多谢

[PP]

能看见别人家的完整合同这件事很不可思议，加解密过程是如何完成的呢，错误配置了别人家的解密？

[8e47e42]

@PP 有疑新算法下 cache 配置出现问题，毕竟 gfs 的 cache 问题也不是一天两天了

[x7395759]

收钱的吗？

[8e47e42]

@x7395759 必须的，G Suite Business，不然哪里会有人理你

说来好笑我们前段时间居然还想升级到 G Enterprise，还好没有升

[janssenkm]

谷歌大叔的 drive 应该类似 ClusterFS, Ceph,HDFS 等，将文件拆成一个个数据块后以分布式方式存储。在某处维护一套索引机制，一个文件有一个唯一标识码，通过标识码和数据包顺序标识引用来实现文件的读写操作。
楼主遇到的问题我猜测是因为这几个原因导致吧，
1. 文件标识码计算方式遇到冲突，也就是出现两个或三个文件计算标识码的算法出现了雷同，这样就会出现文件不一致的情况。
2. 一个文件拆分多个数据包后会将多个数据包分别存放在不同服务器上，刚好某个数据包解析存储的服务器包括冗余服务器接收到该数据包时出现标识码丢失部分内容，过程也许很复杂，但确确实实丢了一位。比如原文件标识码为 1173734, 可丢失一位后变成 117373，两个不同标识码就代表了不同文件，所以就出现某个文件丢失了一个数据块，而另一个文件多了一个数据块。

数据量小时这些问题很难复现，在达到谷歌这种巨巨巨巨巨量数据块下，我觉得还真有可能，而导致故障的原因也许只是某个小小寄存器校验失败。对于巨量存储环境下，这种错误几乎可以忽略了。因为要他不报错还真不可能，只是这微乎其微的概率刚好被楼主遇到了。

给楼主一个建议，分布式存储原理下的数据存储都会有一定几率造成数据包异常，我们只能尽量减少发生概率。有条件的话，
1. 建议存放时做一下校验，本地生成一个 md5，存上去后再抓回来做一个校验，两个值相同时才能认为存入成功。
2. 检查调用的 api 是否使用了老接口，保证全部走 SSL，这个可以防止被污染和篡改。谷歌有些老接口不知还存在否，那可是货真价实的 http，虽然谷歌在努力走全 HTTPS，但也许会有漏网之鱼，刚好这一瞬间遭遇了污染劫持篡改也有可能。

[dxppp]

YouTube 也是在掉链子，谷歌💊
https://www.v2ex.com/t/551225

[skyfree]

还有这么大的 bug? 建议国内使用 G Suite 的公司可以看看我们开发的 G Suite 备份软件 ：CubeBackup https://www.cubebackup.com . 真的是个非常好用的企业数据备份工具

[CrabAss]

关注

[8e47e42]

@janssenkm
我们有帮 Google 做 log 分析（对大家没看错 9102 年谷人希现在都没有处理完这个 critical bug，甚至连 log 分析结果都没有给），基本应验你说的 2，Google Drive File Stream 的虚拟驱动有问题，导致 actually 和 expected 的不同，从而在写入的时候导致错误，具体体现为报错日志和出问题文件的写入时间高度一致，服务器上是不是有更进一步的问题尚不明确，但是 local 的 GFS 是真的有问题，建议大家别用了。

更可怕的是我们做 research 的时候发现了这个： https://www.greyhathacker.net/?p=1041
而这种级别的 bug，Google 根本就没有发任何通知。

[skyfree]

@8e47e42 建议试试我们的备份产品 CubeBackup 哈

[8e47e42]

@skyfree 觉得你们这产品真的能火。。

[skyfree]

@8e47e42 我们的产品质量真的很不错，斯坦福大学都在用。 可目前国内用户只有一个。 :(

[FancyKing]

关注，大谷歌竟然出这种事情，我好几百 G 的文件啊，害怕～～～