我正在尝试使用共享的 Dropbox 文件夹使 HTML 文件可由多人轻松编辑，并且正在使用该选项将 Dropbox 文件夹（重新）安装到某个位置/var/www/。--bind我已为 Dropbox 文件夹设置了 SELinux 上下文，以便其中的项目获得可以读取的httpd_sys_content_t类型httpd（在 RHEL6 上）。这一切都有效，文件可在网站上使用。在 Web 服务器上编辑 Dropbox 文件夹中的文件也有效（保留了 SELinux 上下文）。
但是，当通过 Dropbox 更新文件时（例如，其他人编辑了该文件），接收端的结果文件（在 Dropbox 更新它之后）总是会获得一个上下文user_home_t，因此 Apache 无法读取该文件，所以会出现 403 Forbidden 错误（直到我去手动恢复上下文）。
我尝试将 的上下文设置为~/.dropbox/，httpd_sys_content_t这也有效： 中的缓存（？）文件~/.dropbox/l/获取该上下文，但 中的更新文件~/Dropbox/仍然获取user_home_t。这表明 Dropbox 更新了文件别的地方（大概是通过它的 delta 方法）然后执行相当于mv将其移动到 Dropbox 文件夹的操作（因为 SELinuxmv会保留原点的上下文并cp根据目标重置它）。
笔记：
- 我不想禁用 SELinux（但这样做确实可以解决问题）
- 关于使用
httpd_sys_content_t：我最终可能会创建一个特殊策略来处理这些文件，这可能比仅仅使用更合理httpd_sys_content_t，但我稍后会担心这个问题 - 我可以运行一个小脚本，
restorecon -R每 5 秒或 10 秒对相应的 Dropbox 子文件夹执行一次操作，但我更希望早点发现这一点
那么：在将文件移回 Dropbox 文件夹之前，Dropbox 在哪里创建了新更新的文件？还有其他想法可以尝试吗？
谢谢！
大卫
答案1
在中创建临时文件~/Dropbox/.dropbox.cache/，然后移动到其真实位置，以确保原子更新。
解决方法＃3 应该有效——您可以使用incron，它会在文件发生更改时立即执行命令。