cp默认按umask重置权限，需加-p才保留；mv在同一文件系统内仅更新目录项，权限、inode及元数据完全不变；跨文件系统时mv退化为cp+rm，权限行为同cp。
cp 和 mv 对文件权限的影响本质不同：cp 默认不保留原始权限，mv 则完全不改变权限——因为 mv 不涉及内容写入，只改名或移动；而 cp 是创建新文件的过程，新文件的权限取决于 umask 或显式选项。
mv 不改变权限，只改变位置或名称
mv 在同一文件系统内操作时，底层调用 rename() 系统调用，仅更新目录项（directory entry）指向的 inode 编号，文件数据和元信息（包括权限、所有者、时间戳、链接数等）全部保留在原 inode 中。因此：
- 执行 mv old.txt new.txt 后，new.txt 的权限、UID/GID、修改时间等与 old.txt 完全一致
- 即使目标目录 umask 更严格，也不会影响 mv 后的权限——因为没新建 inode
- 运行中的程序（如正在执行的二进制文件）不受影响，系统仍通过 inode 访问原内容
cp 默认重置权限，需加 -p 才保留
cp 是“创建新文件 + 写入内容”的过程，会分配新 inode，并按当前环境 umask 设置初始权限（例如 umask=0022 → 新文件默认为 644，目录为 755）。原始权限不会自动继承：
PyCharm 2026.2.0.1 Linux版
下载
PyCharm 2026.2.0.1 Linux版提供 JetBrains 官方 2026.2.0.1 版本安装包，适合需要指定 PyCharm 版本进行 Python 项目开发、运行和调试的用户。
- cp a.sh b.sh 后，b.sh 权限通常是 644（即使 a.sh 是 755）
- 要完整保留权限、所有者、时间戳等，必须显式加 -p（等价于 --preserve=mode,ownership,timestamps）
- 若用 cp -r 复制目录，-p 也需一并带上，否则子文件/目录权限全部按 umask 重建
跨文件系统时，mv 实际变成“cp + rm”，权限行为同 cp
当源和目标位于不同挂载点（如 /home 和 /mnt/usb），mv 无法用 rename()，转而先 cp 再 rm。此时：
- 目标文件的权限由 cp 行为决定：不加 -p 就是 umask 默认值；加 -p 才保留原权限
- 原文件被删除，新文件拥有独立 inode，所有元信息需靠 -p 显式复制
- 可用 stat -c "%d %i" file 检查是否跨设备（%d 是 device ID）
上线更新可执行文件的安全实践
避免正在运行的服务因权限丢失或中断失效：
- 不要直接 cp new.bin app —— 可能导致中间态权限错误或覆盖失败
- 推荐做法：rm app && mv new.bin app，确保原子性且权限继承
- 或用 cp -p new.bin app，但需确认目标路径所在文件系统支持硬链接（部分网络文件系统不支持）
