传输的一些建议

[zundaren]

1.用户中断传输是否需要删除远程已传输的部分
2.可以选择是否使用断点续传功能，一些压缩文件重新写入不知道会不会有结构破坏，能做出来对一些超大文件传输很友好
3.低带宽情况下，文件较小的是否可以自动打包压缩，传输完成后自动解压，省去人工操作，比如log，随随便便100m，但是压缩后只有7m左右

[lonnywong]

1、现在 trzsz 是不会主动删除已传输的部分的，如果下次用户传输时加上 -y 选项，会覆盖写。
2、这个其实一直在我的 TODO LIST 中，#10 我打算加一个 -a --append 选项，当文件已存在时，会覆盖写，但是在覆盖写之前，会判断前面的部分是否和将要传输的一致，从不一致的位置开始追加传输。

我的计划是，先实现流水线传输的版本（ 两周前 go 版本终于实现了，还差 py 和 js 版本还没实现呢 ），以提高传输速度。然后在此基础上，再实现 -a 选项，追加的方式实现断点续传。

[zundaren]

1、现在 trzsz 是不会主动删除已传输的部分的，如果下次用户传输时加上 -y 选项，会覆盖写。 2、这个其实一直在我的 TODO LiST 中，#10 我打算加一个 -a --append 选项，当文存已存在时，会覆盖写，但是在覆盖写之前，会判断前面的部分是否和将要传输的一致，从不一致的位置开始追加传输。

我的计划是，先实现流水线传输的版本（ 两周前 go 版本终于实现了，还差 py 和 js 版本还没实现呢 ），以提高传输速度。然后在些基础上，再实现 -a 选项，追加的方式实现断点续传。

删除文件可以加个选项，比如用户不小心选择了100个小文件，很快传了50的，发现传错了，单独一个一个删会很麻烦

[lonnywong]

你是说用户主动停止时，弹出个提示窗口，让用户选择是否直接删除已传输的部分？感觉可以做。

欢迎大家有空时一起来完善这些功能。写代码之前可以先和我沟通，也可以提 PR 过来，不一定要写完再提，可以实现一小部分就先提 PR，然后一起沟通，慢慢完善好再合入 PR。

另外说一下，近期的代码改动可能会比较大，go 版预计在本周末会实现并提交，py 版在实现流水线传输时会改动很大（ 提交时间未定 ），js 版会比 py 版好一些。

[zundaren]

你是说用户主动停止时，弹出个提示窗口，让用户选择是否直接删除已传输的部分？感觉可以做。

欢迎大家有空时一起来完善这些功能。写代码之前可以先和我沟通，也可以提 PR 过来，不一定要写完再提，可以实现一小部分就先提 PR，然后一起沟通，慢慢完善好再合入 PR。

另外说一下，近期的代码改动可能会比较大，go 版预计在本周末会实现并提交，py 版在实现流水线传输时会改动很大（ 提交时间未定 ），js 版会比 py 版好一些。

3.低带宽情况下，文件较小的是否可以自动打包压缩，传输完成后自动解压，省去人工操作，比如log，随随便便100m，但是压缩后只有7m左右

[lonnywong]

3. 默认是会自动压缩和解压的，除非指定 -b 选项。

[0x5c0f]

要不分段传，传完后合并，大文件时候完美解决断线问题

[lonnywong]

要不分段传，传完后合并，大文件时候完美解决断线问题

在这讨论 #10 (comment) ，计划 -y 传输时自动解决断线的问题。

[lonnywong]

v1.1.4 已支持这三个建议。

1、Ctrl + C 中断时，用户可以选择是否保留已传输的部分。

2、用户如果选择保留已传输的部分，那下次再使用 trz -y 或 tsz -y xxx 传输相同文件时，会自动实现“断点续传”的效果，从文件内容不一致的位置继续传输。

3、原来只有 base64 模式时会自动压缩，-b 二进制模式时不会压缩。现在改成自动检测源文件，如果是非压缩的文件，则会自动压缩。也可以通过参数 -c yes 和 -c no 强制压缩或不压缩。