Racket项目中动态库文件被意外删除的问题分析与修复

在Racket 8.15版本中，部分MacOS用户报告了一个严重问题：当运行raco setup命令时，系统会意外删除/Applications/Racket v8.15/lib/目录下的18个动态库文件。这些被删除的文件都有一个共同特征——它们的文件名与/opt/local/lib目录下的库文件存在重名现象。

问题现象

受影响用户发现，在配置文件中设置了(lib-search-dirs . (#f "/opt/local/lib"))后，运行raco setup会导致以下类型的日志输出：

raco setup: deleting: foreign library <lib>/libgio-2.0.0.dylib
raco setup: deleting: foreign library <lib>/libglib-2.0.0.dylib
...

随后，当用户尝试运行DrRacket时，会出现严重错误并导致程序崩溃，错误信息表明关键的系统库已丢失。

技术背景

Racket使用动态库搜索路径(lib-search-dirs)来定位系统依赖库。配置中的#f表示Racket自带的库目录。用户将#f置于首位是希望优先使用Racket自带的库而非系统路径中的库，这通常是为了确保使用特定版本的库文件。

根本原因

问题出在setup/set-core.rkt文件中的库清理逻辑。在检查库文件是否需要保留时，代码错误地处理了"move"模式（一种特殊的库安装模式）的情况。原始代码中，当库处于"move"模式且源文件不存在时，会错误地认为库文件可以被删除。

具体来说，问题代码片段如下：

(or (and moving?
     (not (file-exists? src))
    (same-content? src p))

这段逻辑会导致在"move"模式下，只要源文件不存在（即使目标文件完全正常），就会触发删除操作。

解决方案

Racket核心开发团队确认了修复方案：简化检查逻辑，仅依赖内容比较来决定是否保留库文件。修复后的代码如下：

(same-content? src p)

这一修改确保了：

1. 只有当源文件和目标文件内容确实相同时，才会跳过移动操作
2. 在"move"模式下，已移动的库文件不会被错误删除
3. 未移动的库文件仍能通过内容比较得到正确处理

最佳实践建议

对于需要在Racket中使用系统库的用户，建议：

1. 谨慎设置lib-search-dirs配置
2. 避免将#f放在搜索路径的首位
3. 定期检查库文件完整性
4. 在升级Racket版本后验证关键库文件是否存在

该修复已合并到Racket代码库中，将在后续版本中发布。遇到类似问题的用户可以考虑暂时避免运行raco setup命令，或手动恢复被删除的库文件。