amtoaer / bili-sync

由 Rust & Tokio 驱动的哔哩哔哩同步工具
https://bili-sync.allwens.work
MIT License
348 stars 32 forks source link

Update README.md - compose中指定user,附加简要说明 #102

Closed ky0utarou closed 2 months ago

ky0utarou commented 2 months ago

100

amtoaer commented 2 months ago

我现在对 user 会影响权限这个事情还抱有一定怀疑,因为正常来说文件权限是标准库设置的,设置 user 只会影响文件所有者才对。等后面我写个最小实例验证一下。 目前可以暂时先将这里的表述修改为”项目下载的文件所有者会与该处设置的 user 保持一致,不设置默认为 root“吗? (以及可以在中英文之间加个空格 XD)

ky0utarou commented 2 months ago

目前可以暂时先将这里的表述修改为”项目下载的文件所有者会与该处设置的 user 保持一致,不设置默认为 root“吗? (以及可以在中英文之间加个空格 XD)

当然

因为正常来说文件权限是标准库设置的

我理解的你的意思是,标准库在创建poster.jpg的副本的时候,会把owner和permission原样复制。那按理说不管docker这边是什么用户,最终拿到的两个图片文件也应该是完全一样的。

amtoaer commented 2 months ago

不,我描述的是整个下载过程的文件权限。如果 docker 以 x 用户运行,那么正常情况下:

  1. 新文件夹的 owner 是 x,权限 755
  2. 文件夹里下载的文件 owner 是 x,权限 644
  3. 文件里被 copy 出的 fanart owner 是 x,权限 644

如果用户是 root,那么正常只会影响到 owner 而不会影响到权限。但在你的 issue 截图中,下载的文件权限是 777,而 copy 结果的权限是 000。

如果这个是程序本身的行为,那说明使用 root 用户运行不仅影响到了 owner,还对文件权限产生了影响,这是不符合预期的。也就是我说的那个需要”验证“的问题。

至于你提到的这个是另外的场景。在我的认知里 copy 结果的 owner 会与程序执行时使用的 user 保持一致,并不会 copy 原文件的 owner。

ky0utarou commented 2 months ago

明白了👍