omiku

> > 数据库中已有的哈希是从哪来的？ 如果是Web端计算的话，那 WebDAV 上传的文件怎么办？ 如果是服务端计算的话，违背了存储策略都要支持客户端直传的理念。 > > 只支持Web/App 是一个很合理的限制/需求。对于数据库中已有的文件可以在版本升级时服务端创建后台任务计算，此后都由客户端计算。 要做这个功能势必做取舍，以现有的资源\架构来看，要做到以下约定： 1. 第一份哈希计算安全 - 所有文件的首次哈希值**必须由服务端计算**，计算途径包括： - 文件上传至本机/从机存储时实时计算 - 离线下载任务完成后的异步计算 - 禁止直接信任客户端提交的哈希值（防恶意伪造） 2. 秒传功能启用范围 - 仅限**本机存储**和**从机存储**策略支持秒传 - 排除对象存储/三方网盘（因无法控制哈希计算） 3. 触发入口限制...

1.目的地目录下没有该重命名文件，该目录是一个完全纯净的目录 2.该报错有一定的复现条件： > 在不动主节点的情况下 使用system进行进程守护启动程序会100%复现该错误，而使用./启动程序则几乎没有概率会遇到该问题 > 在给主节点使用全球cdn加速后 使用system进行进程守护启动程序则99%概率不会失败但是仍有概率会触发一次Remote returns unexpected status code: 5xx 后成功转移到目标存储 在使用从机存储上传大文件时遇到一个问题，可能对该报错有一定的帮助：   从机存储的上传完成后会去请求主节点，这时如果请求失败会重置整个上传队列，导致断点续传功能实质上的失效，非常的影响使用体验