请在2024年Clojure状态调查!中分享您的想法。

欢迎!请查看关于页面以获取更多关于如何使用本网站的信息。

0 投票
工具

DBFS(Databricks文件系统)没有正确实现POSIX权限。
特别是bash标志"-w"无法正确检测非可写项目目录。

因此,在我这个案例中,在DBFS上启动Clojure尝试写入当前目录的.cpcache文件,但由于实际上它是只读的而失败,无法覆盖。

有关详细信息,请参阅此处和错误信息
https://clojurians.slack.com/archives/C03S1KBA2/p1726750856210489

在DBFS上也无法更改UNIX文件权限

只是看到了这个相关的jira
https://clojure.atlassian.net/browse/TDEPS-119
我认为引入CLJ_PROJECT_CACHE的原方案将解决我当前的问题。

1 答案

0 投票

这听起来像是DataBricks的问题吗?

是的,或者我们接受“-w”不是检测“只读”目录的可靠方法,然后找到一个让Clojure脚本不依赖它的方法,而不强制另一个目录。

不确定是否有其他文件系统存在类似问题。

DBFS不支持任何“文件权限”,所以这个问题永远不会在DBFS中解决
当前的逻辑也不允许在文件系统“满”的情况下更改.cpcache的位置,例如。(满,但可写)
或者在其他原因,而不是“只读”的情况下,我不喜欢它的默认位置。
类路径往往很长,必须传达给Java进程。您可以通过命令行传递(但许多系统有进程行长度限制),或将其写入文件并通过这种方式传递。Clojure CLI执行后一种方法,但这需要写一个文件。有多个地方可以写入该文件以及检测正确位置的逻辑。如果系统报告说可以写入但不能,或者不能写入,我不知道CLI可以期望对此做什么(这似乎对下载Maven库、下载git库、准备git库以及CLI的工具.deps的许多其他功能来说是问题)。

尝试将文件写入以测试其能否写入不成功,因为我们使用文件的存在来检测缓存的文件是否存在。添加更多的环境变量不受欢迎 - 已经有太多的配置选项,而且在很多情况下这种逻辑存在于多个位置(bash 和 tools.deps clojure),这些位置必须保持同步,并且所有读取/写入缓存的代码都必须达成一致。所有这些选项都有不同程度的缺点。
...