Use an internal index to more accurately track renames on macOS

未关闭
#49 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

还没有人认领这个 Issue。

评估

难度
5/5
预计耗时
一周以上
新手友好度
30/100
Issue 类型
功能
描述清晰度
需要澄清
活跃度
停滞
技术栈
java, macos
领域
operating-systems

调研方向

首先追踪 macOS FSEvents 的处理方式，以及当前如何解释 ITEM_RENAMED、ITEM_CREATED 和 ITEM_REMOVED。重现 issue 中描述的三种移动情况，然后将完成标准定义为：能够区分移入监视范围、移出监视范围以及在监视范围内的移动，而不是仅依赖文件系统存在性检查。

由索引模型根据 Issue 内容生成。

描述

enhancement

When a file is moved and we're using the native FSEvents API on macOS, it issues native events with flag ITEM_RENAMED set, but not flags ITEM_CREATED or ITEM_REMOVED. Typical cases include:

  1. Moving a file within the watch scope. In this case, there are two native events: one for the source (logically: delete), and one for the destination (logically: create).
  2. Moving a file into the watch scope. In this case, there is one native event, for the destination (logically: create).
  3. Moving a file out of the watch scope. In this case, there is one native event, for the source (logically: delete).

Because flags ITEM_CREATED and ITEM_REMOVED aren't set, the native events in cases 2 and 3 are indistinguishable. Currently, this is solved by asking the file system if the file exists: if it does, we assume it's case 2; if it doesn't, we assume it's case 3. However, this can be inaccurate (because things can have happened to the file between the native event was issued and asking the file system). A more accurate approach could be to maintain our own index.

主要语言
Java
星标
1
派生
0
平均合并
14 小时 40 分钟
30 天内合并 PR
1

贡献指南

这个仓库没有索引到贡献指南

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

SWAT-engineering/java-watch 的其他 Issue

查看 SWAT-engineering/java-watch 的全部 Issue

相似的 Issue

更多 Java Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。