file.setexecutable() 在 linux 下仅当文件系统支持权限位且进程有 fchmod 权限时才真正生效；nfs、fat32、部分容器卷会静默失败，需用 ls -l 实际验证，而非依赖返回值。
File.setExecutable() 在 Linux 下是否真能生效
能生效，但仅限于文件系统支持权限位（如 ext4、XFS），且 Java 进程有对应目录的 fchmod 权限。NFS、FAT32、某些容器挂载卷（如 Docker 的 tmpfs 或 rootless bind mount）会静默失败——调用返回 true，但 ls -l 看不到 x 位。
验证方式不是看 Java 返回值，而是立刻用系统命令确认：
ls -l /path/to/script.sh
如果没变，说明底层不支持或权限不足。
Java 代码里调用 setExecutable(true, false) 的含义
setExecutable(true, false) 表示「仅对文件所有者设执行位」，等价于 chmod u+x；setExecutable(true, true) 是「对所有者、组、其他用户都设」，即 chmod a+x。多数脚本只需所有者可执行，用 false 更安全。
常见误写是传 true 却没意识到它会开放 group/o 权限，在多用户环境可能引发安全问题。
- 脚本由当前用户生成 → 用
file.setExecutable(true, false) - 脚本要被同组其他进程调用 → 先
chown :groupname，再用setExecutable(true, false)+setGroupReadable(true)配合 - 绝对不要对临时目录下任意路径无条件调用
setExecutable(true, true)
为什么 chmod +x 手动可以，Java 却失败
根本原因通常是：Java 进程运行用户对目标路径没有 write 权限（修改权限位需要目录的写权限），或文件在只读挂载点上。
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
典型错误现象：
-
file.setExecutable(true)返回false - 日志没报异常，但后续
Runtime.getRuntime().exec()报java.io.IOException: Cannot run program "...": error=13, Permission denied
排查步骤：
- 检查
ls -ld /path/to/—— 目录是否可写？ - 检查
mount | grep $(df . | tail -1 | awk '{print $1}')—— 是否ro挂载？ - 用
strace -e trace=fchmod java YourApp看系统调用是否返回-EPERM或-EROFS
更可靠的替代方案：直接调用 chmod 命令
当 File.setExecutable() 不稳定时，绕过 Java 文件 API，用系统命令更可控：
Process p = Runtime.getRuntime().exec(new String[]{"/bin/chmod", "u+x", "/tmp/myscript.sh"});
p.waitFor();
注意点：
- 必须用
/bin/chmod而非chmod，避免 shell 查找路径失败 - 不要拼接字符串（如
"chmod u+x " + path），防止路径含空格或特殊字符被截断 - 检查
p.exitValue()是否为 0，非零需读取p.getErrorStream()
这招在 CI/CD 流水线、Docker 容器中尤其常用——因为环境更可控，且规避了 JVM 对文件系统抽象层的限制。
真正麻烦的不是怎么设权限，而是你没法提前知道目标文件系统是否支持。每次部署前最好加个探测逻辑：生成测试文件 → 尝试 setExecutable → 再 ls -l 校验。
