功能建议

[qtline]

应用场景：定期备份至天翼云 （如群晖NAS，Linux服务器），通过计划任务执行备份，因为天翼云有中国电信作为后盾相对其他某度某云某60要 靠谱。

目前问题：虽然增加了覆盖上传已存在文件功能参数，但是现在的逻辑是直接将已存在文件移动至回收站，然后重新上传，文件量以及小文件到时无所谓，但是如果文件过大或者文件量过大，目前的这种逻辑就有点浪费设备资源及占用带宽了。

功能建议：直接检查对比文件ID或检查文件名、文件大小、文件日期，如果 一致即可跳过此文件上传。这样就之后针对有更新文件进行上传，节省资源及减少带宽占用，当然时间效率也会提高。

[tickstep]

v0.0.7版本增加了秒传功能，再次上传相同的文件几乎不占带宽了。

[qtline]

v0.0.7版本增加了秒传功能，再次上传相同的文件几乎不占带宽了。 测试了下py版（https://github.com/Aruelius/cloud189/）的秒传，似乎还是有些问题， 我首次上传了个text.txt 内容123 ，修改内容为456 再次上次提示 云端存在，-F 强制上传多了+日期命名的版本 希望go版能很好处理

[qtline]

对了增加个 ”单任务模式“ 的说明 比如 cloudpan189-go > login > upload 123.txt /bak --ow >recycle delete -all

[tickstep]

v0.0.7版本增加了秒传功能，再次上传相同的文件几乎不占带宽了。 测试了下py版（https://github.com/Aruelius/cloud189/）的秒传，似乎还是有些问题， 我首次上传了个text.txt 内容123 ，修改内容为456 再次上次提示 云端存在，-F 强制上传多了+日期命名的版本 希望go版能很好处理

这个需求结合 秒传 和 覆盖上传(-ow) 两个选项即可满足，应该是没有问题，你可以试试。

[qtline]

v0.0.7版本增加了秒传功能，再次上传相同的文件几乎不占带宽了。 测试了下py版（https://github.com/Aruelius/cloud189/）的秒传，似乎还是有些问题， 我首次上传了个text.txt 内容123 ，修改内容为456 再次上次提示 云端存在，-F 强制上传多了+日期命名的版本 希望go版能很好处理

这个需求结合 秒传 和 覆盖上传(-ow) 两个选项即可满足，应该是没有问题，你可以试试。

刚刚测试过 非常Nice

[qtline]

v0.0.7版本增加了秒传功能，再次上传相同的文件几乎不占带宽了。 测试了下py版（https://github.com/Aruelius/cloud189/）的秒传，似乎还是有些问题， 我首次上传了个text.txt 内容123 ，修改内容为456 再次上次提示 云端存在，-F 强制上传多了+日期命名的版本 希望go版能很好处理

这个需求结合 秒传 和 覆盖上传(-ow) 两个选项即可满足，应该是没有问题，你可以试试。

覆盖上传(-ow)可否增加一个（比如-ow rd） recycle delete <file_id 1> <file_id 2> <fileid 3>的参数 ^^ （目的：避免任务计划产生的回收站文件过多，混淆日常使用丢入回收站的文件，也是可选参数 酌情使用）

[tickstep]

v0.0.7版本增加了秒传功能，再次上传相同的文件几乎不占带宽了。

测试了下py版（https://github.com/Aruelius/cloud189/）的秒传，似乎还是有些问题，

我首次上传了个text.txt 内容123 ，修改内容为456 再次上次提示 云端存在，-F 强制上传多了+日期命名的版本

希望go版能很好处理

这个需求结合 秒传 和 覆盖上传(-ow) 两个选项即可满足，应该是没有问题，你可以试试。

覆盖上传(-ow)可否增加一个（比如-ow rd） recycle delete <file_id 1> <file_id 2> <fileid 3>的参数 ^^ （目的：避免任务计划产生的回收站文件过多，混淆日常使用丢入回收站的文件，也是可选参数 酌情使用）

这个可能搞不了，天翼云盘回收站无法通过file id清理文件

[chenall]

@tickstep

上传时以下参数改成5可以直接覆盖上传（不需要删除）。

cloudpan189-api/cloudpan/app_file_upload.go第184行

"opertype": "5",

另外建议可以在检测同名文件的时候直接判断MD5是否和本地一致，如果一致直接跳过上传。

[chenall]

一些建议

1. 增加一个本地数据库（记录已上传文件的信息），下次上传之前先从数据库查找。 有找到先判断是否有更新，没更新就跳过，有更新就覆盖上传，这样就实现了一个备份的功能，如果再加上同步删除就是同步 盘的功能。
2. 现在扫描上传的文件是先扫描完才开始上传的，建议改成同步进行。 这个主要是当需要上传的目录里面文件比较多的时候会有一个很长时间的“假死”状态，我刚开始以为是卡死了。后面查了代码才明白，自己尝试简单修改了一下，应该是效果挺不错的说(已经作为附件上传，感兴趣的可以下载测试，应该可以明显感觉到“反应”变快了）。

修改内容：

1. 扫描和上传同步进行。
2. 使用-ow参数时如果该文件已经存在并且未修改（简单通过MD5判断），不再进行上传操作。

cloudpan189-go-mod.zip

源码我有空整理一下再上传。

关于第一点有感兴趣的吗？

[tickstep]

@tickstep

上传时以下参数改成5可以直接覆盖上传（不需要删除）。

cloudpan189-api/cloudpan/app_file_upload.go第184行

"opertype": "5",

另外建议可以在检测同名文件的时候直接判断MD5是否和本地一致，如果一致直接跳过上传。

opertype这个试了一下，确实可以。 但是家庭云并不支持这个参数，为了保持功能的统一，所以还是采用以前的方式先。 这个覆盖的功能我在api里面开放出来给其他需要的人使用，感谢反馈

[tickstep]

一些建议

1. 增加一个本地数据库（记录已上传文件的信息），下次上传之前先从数据库查找。 有找到先判断是否有更新，没更新就跳过，有更新就覆盖上传，这样就实现了一个备份的功能，如果再加上同步删除就是同步 盘的功能。
2. 现在扫描上传的文件是先扫描完才开始上传的，建议改成同步进行。 这个主要是当需要上传的目录里面文件比较多的时候会有一个很长时间的“假死”状态，我刚开始以为是卡死了。后面查了代码才明白，自己尝试简单修改了一下，应该是效果挺不错的说(已经作为附件上传，感兴趣的可以下载测试，应该可以明显感觉到“反应”变快了）。

修改内容：

1. 扫描和上传同步进行。
2. 使用-ow参数时如果该文件已经存在并且未修改（简单通过MD5判断），不再进行上传操作。

cloudpan189-go-mod.zip

源码我有空整理一下再上传。

关于第一点有感兴趣的吗？

扫描和上传同步进行。 使用-ow参数时如果该文件已经存在并且未修改（简单通过MD5判断），不再进行上传操作。 》建议在最新的代码上修改好，欢迎提交PR

[chenall]

已经实现了备份的功能。

本来打算使用bbolt数据库的，不知为什么添加记录时很容易崩溃报错，我找不到解决方法所以就使用sqlite了。