Cyberduck中B2大文件续传失败问题分析与修复

在文件传输工具Cyberduck与Backblaze B2云存储服务的集成中，用户反馈了一个关于大文件续传失败的典型问题。该问题揭示了在特定场景下API参数传递异常导致的操作中断，值得开发者深入分析与学习。

问题现象

当用户尝试通过Cyberduck上传大文件至B2存储时，若中途暂停后尝试续传，系统会抛出异常导致续传失败。通过日志分析发现，问题出现在b2_list_parts接口调用环节，其中maxPartCount参数被错误地设置为字符串"null"而非预期的整数值。

技术背景

Backblaze B2云存储服务为支持大文件上传，实现了分段上传机制。当上传过程中断后，客户端需要通过b2_list_parts接口查询已上传的分段信息，以确定续传起始点。该接口设计有三个关键参数：

• fileId：标识目标文件
• startPartNumber：查询起始分段号
• maxPartCount：限制返回的分段数量

问题根源

在Cyberduck的实现中，当首次查询分段信息成功后（返回nextPartNumber=101），后续查询请求错误地将maxPartCount参数序列化为字符串"null"。这与B2服务端预期的整数类型参数不匹配，导致API调用失败。这种类型不匹配问题源于Java对象到HTTP查询参数的转换过程中未正确处理空值情况。

解决方案

项目维护团队通过修改底层Java API库的请求构建逻辑，确保：

1. 当maxPartCount为null时，直接省略该参数（B2服务端默认会返回全部分段）
2. 非null值时严格保证参数类型为整数
3. 优化参数序列化逻辑，避免类似类型转换问题

经验总结

这个案例为开发者提供了三个重要启示：

1. 云存储API集成时需严格遵循参数类型规范
2. 空值处理需要特别关注，不同服务对省略参数和显式null可能有不同处理
3. 分段上传等长时间操作需要完善的错误恢复机制

该修复已合并至项目主线，用户可在后续版本中体验更稳定的大文件续传功能。对于开发者而言，理解这类边界案例有助于构建更健壮的云存储集成方案。