小编rib*_*ram的帖子

有一个讨论,连续的FSEventStreamEventId可用于检测kFSEventStreamEventFlagItemRenamed事件的旧名称和新名称.这似乎适用于我对基本重命名案例的测试.但是,这似乎在以下情况中崩溃:

• 监视目录test_dir以查找事件
• 文件A存在于test_dir中
• 从bash终端发出命令mv AB;在test_dir中触摸C; mv CA.

这会导致事件:

2012-11-06 18:13:01.246 test[45080:1603] event [60095818] [10800] [/Users/tim/test_dir/B]
2012-11-06 18:13:01.248 test[45080:1603] event [60095824] [10900] [/Users/tim/test_dir/C]
2012-11-06 18:13:01.253 test[45080:1603] event [60095825] [10800] [/Users/tim/test_dir/A]

事件位0x10800 ="文件重命名"和0x10900 ="文件创建/重命名"

(来自FSEvents.h)

kFSEventStreamEventFlagItemCreated = 0x00000100
kFSEventStreamEventFlagItemRenamed = 0x00000800
kFSEventStreamEventFlagItemIsFile = 0x00010000

在这种情况下,似乎A被重命名为B的事实已经丢失.

我希望看到像A的60095817 10800这样的事件.

任何人都可以确认这种行为,如果有的话,是否有人对如何处理这种限制有任何想法,而不必维护目录内容的单独表示并重新扫描/比较整个目录？

我正在测试OS X 10.8.2.

编辑:刚刚发现另一个讨论,表明这可能是一个更多的重命名问题.

在安装新版本时,我在WiX 3.6中使用<MajorUpgrade> 强制卸载我的应用程序的先前版本.我的应用程序将扩展DLL文件安装到Windows资源管理器中,因此卸载"正在使用的文件"列表资源管理器并默认关闭列出的应用程序.这确实会杀死Windows资源管理器,因为我的shell消失了(这对用户来说有些刺耳),但是我仍然会收到一条错误消息,说明并非所有应用程序都可以关闭并指出需要重新启动.我的偏好是避免这种颠簸并跳过"使用中的文件"对话框,只是告知用户最后需要重新启动.有没有办法告诉WiX跳过"使用中的文件"对话框？

我需要在Windows和OS X上生成的文件名之间创建映射.我知道OS X "将所有文件名转换为分解的Unicode"但是,"大多数卷格式都不符合这些普通表单的确切规范"

因此,使用标准的UTF8 API将Windows名称转换为NFD并确保我拥有正确的OS X名称似乎并不是一件简单的事情.有没有办法确定实际的OS X文件名是什么,而无需在文件系统中实际创建文件,然后扫描目录以查看实际创建的内容？