571335_zh-CN

liliconcom

当目录可写时，目录是否可写返回 0我有一个问题，以前对网络驱动器具有只读访问权限的用户在提供读写访问权限时仍然会导致目录 writable() 在被授予访问权限后在目录中返回 0。 用户已验证他们可以在相关目录中打开文件夹、创建文件、更新文件以及删除文件。 其他人以前也遇到过这个问题。 这使得设置有关保存目录的数据验证变得困难。自动化和脚本编写视窗回复: 当目录可写时，目录是否可写返回 0我的猜测是你是对的。 我的 IT 团队可能只是更新要启用的用户的首次写入状态。 但是，当更新 is 目录可写的用户权限以返回 0 时，jmp 可能要求第二个“古老”字段不是只读的（完全未选中）。 我的 IT 团队没有意识到他们也需要修复该位置......

这是有道理的，这不是端到端测试。 因为他们显然具有读写访问权限。

已提前运行 is is directory 命令以确认路径输入正确且存在。 它确实返回 1。 感谢您建议将其作为初步健全性检查。

我还将要求 IT 检查该目录的驱动器映射。 如果我发现解决方案，我会回来查看。

任何人都有一个 jsl 脚本，它可以执行端到端版本的目录可写，我可以将其插入以进行 JMP 正在执行的检查？ 从长远来看，这可能是解决此问题的更好方法……回复: 当目录可写时，目录是否可写返回 0

在 IsDirectoryWritable() 之前使用 IsDirectory() 验证路径是否存在。 如果目录不存在（拼写错误等），IsDirectoryWritable 报告 false，而不是错误。 IsDirectory() 对于名称错误报告 false。 可能是驱动器映射问题？

 

在我的快速测试中，该函数似乎是在测试 Windows 权限，而不是实际进行端到端测试。 对于连接到 VirtualBox 的 Linux 驱动器，无论 Linux 权限如何，它始终报告 true（可写）。

 

这是我所看到的：

User PermissionsUser Permissions用户权限Admin PermissionsAdmin Permissions管理员权限

我以用户身份运行，而不是管理员身份运行，没有写权限的文件夹有 isDirectoryWritable==false。

 

最后：有一个我认为不涉及的古老选项：

Directories don't really have a read-only attribute.Directories don't really have a read-only attribute.目录实际上没有只读属性。

该方块是第三种状态，既不是选中的也不是未选中的。

https://superuser.com/questions/1580751/folders-created-with-read-only-attribute-and-i-cannot-remove