文件夹权限和 "/" 文件的问题
chenglu opened this issue · comments
感谢 JuiceFS 团队制作如此优秀的工具，近期在从 七牛云 以 SFTP 传输数据的时候发现了两个问题：
第一个：目标服务器的文件夹权限发生了更改：
755 是正确的权限（我看到其他的都是这个权限），而传输过去的文件夹是 700。由于在 Unix 系统里采用了「只读」权限的策略，导致只读权限账号无法读取 700 权限的文件夹内容：
请帮忙查证一下看是否有必要在这里进行一些修补或者完善，需要指明的是，这个问题并不是在最新的 0.1.0 中出现，而且是很偶然的。
第二个：特殊文件处理 比如 "/" 这样的文件：
因为使用了镜像存储，所以七牛云会把诸如 example.com/assets/ 和 example.com/assets// 在存储系统里认为是两个文件，所以这可能是如下报错产生的原因：
2020/01/30 05:07:55.263889 <ERROR>: Failed to copy /: sftp: "Failure" (SSH_FX_FAILURE)
请帮忙查证一下这个问题，需要指明的是，这个问题仅出现在最新的，从 releases 里下载的 0.1.0 版本中存在，之前应该是没有这样的问题。
感谢制作这个优秀的工具并持续维护。
以上，
谢谢！
第一个可以帮忙确认下 umask 么, 不过你说是偶发... 也可能是在偶发的时候 umask 突然改变了?
指的是目标服务器的 unmask 权限对吧？
@chenglu 其实是想确认一下:
- 「偶发」是指一次传输中偶然有几个目录权限变 700 了还是说偶然有一次传输中全部目录变 700 了
- 在变成 700 的时候对应进程的 umask 是啥, 可能会需要去
strace一下 sshd 的子进程来跟踪, 因为我尝试过了还没有复现...
感谢!
@chenglu 第二个问题也想确认几个哈:
- 是从七牛的对象存储同步到自己的服务器上么,
./juicesync qiniu://[ak]:[sk]@[ep] user@hostname:dirname这样子么? - 七牛对象存储里有 key 为
test.com/和test.com//的两个对象对吧?
我本地按照上述情况也没有办法复现 Failed to copy /: sftp: "Failure" (SSH_FX_FAILURE) 错, 可能是复现方法不对, 所以想请问一下复现的方法, 感谢
目前 sftp 对 test.com// 这样的 key 的处理是会变成 /[path]/[to]/test.com 这样的一个文件, 因为 POSIX 标准的文件系统里单个 / 结尾的 pathname 是目录, 多个 / 结尾的跟单个结尾的相同...
辛苦，我的目标服务器是一间提供数据备份的公开服务，所以可能在 Unix 系统上有一些权限修改，我咨询了他们的人，他们的回复说：
The default mask (i.e. when touching a file) is 644 and the ownership will follow the user logging in. Usually a mask will be preserved from the source when uploading a new file/directory. The user and group will still be "reset" to your login ID and group since you're not root on our systems which means you cannot set files to have other UID/GIDs.
However, you can preserve original ownership/permissions:
rsync -av --rsync-path="rsync --fake-super" /source {username}@{server}:{path}
传输时候的「偶发」印象里应该是只有截图里的两个文件出现了问题，这两个文件在站源的创建时间分别是：
- 2019/10/1, UTC+8 上午7:54:45
- 2019/8/23, UTC+8 上午1:54:44
所以估计并不是在某一次传输过程中出现了这样的问题，strace 感觉很高端，下次复现的时候再说吧～
问题二的话，我删掉了七牛里的 xxx/ 和 xxx// 文件，再次同步就没有出现这样的问题了，哈哈。
第二个已经解决，第一个等能复现了再开，暂时关闭。
👍
昨天遇到了类似的问题，src的owner和group是mysql，但是同步后的dest，全变为root；
此前的多次测试使用中，包括同一个src，未发现类似问题。
这次是容器启动失败，提示权限不足才发现。所以暂时无法提供有效的复现提示。
拷贝的时候有加上 --perms --dirs 参数吗？没有的话，就不会拷贝权限信息。
确实没有，是我疏漏了。
但是同一个src，同步的操作命令参数都一样，dest的主机一样，目录不一样。权限信息前后不一致确实有点困惑。
不过我还是补充下操作命令，把参数加上