如何让浏览器支持上传超大文件夹?

2019-05-02 12:18:25 +08:00
 a132811

如果上传超过 150 多万个文件的文件夹(视你的机器配置,我的配置是 16G 内存) 浏览器就会 crash (原因是浏览器会全量读取 file stat list) https://codepen.io/ahuigo/pen/WWPeLP

排除方案:

  1. 将文件夹打包再上传:按照我们的场景,每次打包 1TB 硬盘是不现实的 —— 时间长(打包、解包)、还需要备用一块硬盘, 运营是不愿意手工打包的
  2. 采用非 web upload 方案, 本地客户端没有 FileAPI 限制(开发成本大)

替代方案:

  1. 开发命令行版的上传方案,没有 UI 交互,非常不人性化

https://bugs.chromium.org/p/chromium/issues/detail?id=958679

4493 次点击
所在节点    问与答
17 条回复
jamesxu
2019-05-02 12:25:46 +08:00
这种场景不适合 web,开发一个本地客户端能有多大成本?
JmmBite
2019-05-02 12:53:23 +08:00
测试了一下,四十万的数量就 Crash 了,还是写个客户端吧,逻辑差不多,加一个目录扫描功能。
azh7138m
2019-05-02 12:59:16 +08:00
这是一个 XY 问题

如果是同步场景建议 rsync。
如果是办公数据备份,请使用专业存储,本地 nfs 挂载。
airyland
2019-05-02 13:46:09 +08:00
不一定要命令行,用 electron 写 ui 来指定上传目录,node 来遍历异步执行。
a132811
2019-05-02 15:18:58 +08:00
@azh7138m 3ks, 我们的场景比较特殊,不可以直接用 rsync 同步。
我们的存储是通过 s3 或者 oss 协议传到 阿里、AWS、自建存储,在这个基础上要有上传前后对包文件夹(符合特定名字的文件夹就是包)的监控:上传前预处理+后处理、权限方面控制、相关任务流逻辑、每个包进度监控

@airyland @jamesxu
现在已经开发的 web 版主要就遇到这一个问题,能解决此问题话就尽量不搞客户端(适匹多端、客户端更新 也是浪费精力)
JamesR
2019-05-02 15:39:59 +08:00
“尽量不搞客户端(适匹多端、客户端更新 也是浪费精力)”,搞笑。
a132811
2019-05-02 15:48:22 +08:00
@JamesR 这个只是我们大量需求的一个,我们组不是专门搞客户端的。哪里搞笑了?
xiaogui
2019-05-02 15:56:33 +08:00
这种场景不适合 web +1
JamesR
2019-05-02 16:00:02 +08:00
@a132811 #7 浏览器原本就不是用来干这个的,百度网盘为什么要做个客户端呢,你有没有想过?它为啥不弄纯 Web 浏览器上传下载呢?

又要马儿跑(浏览器不用安装客户端),又要马儿不吃草(浏览器啥都能干)那是不可能的。

要么自己老老实实手动慢慢传文件,要么就自学开发个程序全自动帮你传。
azh7138m
2019-05-02 17:11:10 +08:00
@JamesR 百度的问题和楼主不一样,大量的网盘可以直接使用
比如 mega onedrive googledrive,强制客户端只是百度的运营策略。


那建议 https://electronjs.org 包一下吧,成本低。这么复杂的需求为啥不搞个端。。。
a132811
2019-05-02 17:19:00 +08:00
@JamesR 很多事过去是不可能,以后未必不可能。浏览器的边界一直在延伸,PWA/service-worker、webRTC 在过去很多人都没有想过。
---------------------
话题又扯远了。目前这个问题在官方支持前应该是无解。只能客户端和命令行了。我比较偏向于 flutter
JamesR
2019-05-02 17:26:51 +08:00
@a132811 #11 请问能纯浏览器实现自动化批量(包括选择打印机,纸张等)打印吗?
它为啥不能呢?还有它为啥不设计能读取修改本地用户文件呢?
等等等等,这和浏览器原本的的设计用途有关。
ipwx
2019-05-02 18:23:10 +08:00
@a132811 恰恰相反,曾经用 IE + ActiveX 一定能实现楼主的需求。Java Applet 也能实现。Flash 的话,似乎好像也能实现?

但是我们大家都看到了,这些技术就是漏洞百出的筛子,能让黑客轻易控制用户计算机。所以现在的浏览器反而收窄了边界。
ochatokori
2019-05-02 19:21:30 +08:00
浏览器确实不合适,甚至难度非常大,至少现在来说
既然你们已经开发了一定程度的 web 版,建议移植到 electron 上,把这活给下层的 node 干,这样工作量比重新开发客户端快多了还能解决问题
a132811
2019-05-02 21:19:29 +08:00
@JamesR 你是不是想告诉我 浏览器的所涉及的安全问题?我当然明白这个涉及到用户授权的问题,我讨论的范围也是用户要点击 button 选择文件夹后,“授权”后才能做的事情(现在 chrome 不就支持这么做么)。我没有说自动读取用户的文件系统呀。

activeX/applet/flash 之类的已经不属于浏览器的自身了。只能说明过去浏览器功能支持太有限。

@ochatokori 谢谢你的意见 electron 或许是一个不错的选择
Tomorr
2019-05-03 11:38:02 +08:00
WebAssembly wasm 不知道这个玩意有不有得搞,(谷歌的图片压缩 squoosh 等等)
a132811
2019-11-25 17:42:42 +08:00
wasm 不是解决这种 api 问题的。wasm 未来用来写 cpu 密集的逻辑。

5 个月后,chrome 出了 native file api,可以说彻底解决了访问本地文件 、文件夹的问题:
https://web.dev/native-file-system/

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

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

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX