两点：1.bing 极差，无论英文还是中文，如果不是因为我在公司的电脑上把百度指向了 127.0.0.1，应该没有使用它的机会。当然，由于它对 msdn 的天然友好，对我这种 windows 开发还是比较有用处。ps：bing 的壁纸还是不错
2.谷歌的中文已经不行了，相对谷歌还能正常访问以及还能通过改 host 访问的时代，现在谷歌的中文搜索是垃圾级别

@zarte 没有技术问题，读取不锁文件写入不锁文件就行了。锁文件这个操作是上层的实现做的，并非系统读写文件接口一定会锁住文件。
实际上你想实现多个写多个读都没问题，操作系统允许你这么干。（当然，多个写你最后写出来的是什么东西就听天由命了）
给你个实例：百度网盘的视频预览功能，实际上就是边下边读

这个不叫木马……

这不是已经讨论过无数次么，技术上和开一个录音软件有什么区别？

@shenlanAZ 迅雷出错的是有的。不过自从迅雷变成 bt 客户端后，它大多时候走的是 bt 协议，而 bt 协议是有严格校验的。
实际上多看看迅雷下载日志是能找到块重传的记录的。

这事 hr 还真不见得背锅……吃到 c 这个事主要还是 leader 的原因吧

只是要实现写的时候读取的话很容易啊。实际上所不锁完全看 ftp 的实现。比如 windows 的 createfile 完全可以让你做到这些，linux 我不熟，但是从 fd 下手应该也是没问题的。
这个需求的问题在于为啥要这么干，比如一个压缩包，你不作特殊处理从头到尾边下边读是毫无意义的（ zip 的文件表在包结尾）。实现起来都是没有任何难度的。

不做额外校验的话确实是不可能真正保证文件准确的，其实单纯 http 下载出问题的情况很多的。比如早期直接用 http 下电影的年代，电影某一块损坏是非常常见的事（某些帧绿了，花了）。但是问题很多是出在其它方面，比如多线程下载软件断点续传的 bug。http 封包本身出问题的概率相当之小，从我个人的经验还没碰上，如果 http 或 ftp 传输文件错误的话，首先考虑服务器内存是不是有问题，云服务器之前，我们找机房托管 ftp 服务，由于内存损坏导致问题的居然概率颇高，嘛，虽然用的只是便宜机房……
真正要保证文件准确的，比如 bt 这种文件共享方式是要对文件的每一块进行校验，如果有某一块校验不通过，会重新下载这一块。

@SaltyLeo 我给弄的是 pc 端，遍历指定的目录，然后从电子书（ epub、mobi 甚至 pdf，不过网上来的 pdf 基本没有什么可以提取的信息）中解析相应的信息。主要是方便自己管理自己硬盘中的书，然后方便自己传输到不同设备上。
毕竟我硬盘上长期积攒下来有 300GB 的文件呢（而且还会增长），不借助工具基本没可能知道自己有哪些书，某本书是不是已经下载过了。

@LeroyMooney 有感而发。妈宝男说不定羡慕楼主呢

楼主的话可以一言蔽之：别人的都是好的。
实际上……

由于手头有 300GB 电子书，所以我正在给自己写一个管理工具，计划中也要弄点粗略的预览。不过目前只是一个 helloworld、离能称之为 demo 都还有很远的距离。不过如果说终极目标，大概也就是一个劣化版的 calibre。calibre 已经把我能想到不能想到的功能都做完了。
光是阅读功能，个人开发起来也是够呛的，如果不用现成的库而是自己敲代码怕是要写一年（至少）

@k9982874 不但平舌卷舌难分，我连 rnl 都分得困难……

@woyao 是的

@avrillavigne 医护人员是第一线啊，比挤火车的大家感染机会高多了

@keepeye 减少活动吧，拜个年恐怕还是可以的，庙会就……
再过几天北京城就成空城了，情况也会好不少

@starcraft 刚看同事发的微博截图，武汉某社区四万余家庭共吃团圆饭
果然是武汉都不慌，我们慌个锤子（滑稽）

打听了一下，那哥们武汉人……
好吧好吧，大家谨慎点就行了，也不要太害怕了，容易自己把自己吓出病来。
这个时候身体素质才是最重要的。第一时间肯定是靠自己的免疫力的。