macos - 如何在 Mac OSX/Finder 中复制/复制目录后触发脚本

Question

在 Snow Leopard 中，每当用户在 Finder 中复制目录时，我想触发脚本/代码。我怎样才能做到这一点？

我一直在寻找文档，但我对这类工作有点太新了，无法识别正确的方法。

动机 :如果一个目录在版本控制下，比如 git 或 hg 或 svn，并且用户复制了该目录，那么我想运行一个脚本来搜索原始目录，然后在版本控制中创建一个“标签”。如果用户重命名目录，比如在 10 秒内，那么重命名将成为该标签注释的一部分。我最终还想添加一些覆盖图标来指示目录的版本控制状态。

扩大动力 : 我面临的问题是版本控制软件，如 git 和 hg，在我看来太复杂了，因为它与文件系统太断开，并且充当了影子文件系统。我是版本控制的忠实拥护者，并且已经使用了很多年——但我也看到了部署的局限性，因为它的复杂性。现实情况是，如果更易于使用，将会有更多代码处于版本控制之下。

我正在研究创建一个不需要终端访问的更易于使用的 VCS 系统的可行性。想象一下，如果 Apple 将其作为 finder 和/或 iLife 的一部分，版本控制(代码)会是什么样子——简单但足够好。实际上，我显然不会重新发明 vcs，但我希望为 hg 之类的东西构建一个模块/插件，并将其与重新设想 vcs 如何用于以查找器为中心的 UI 结合起来a - 全部为更休闲的程序员创建一个更简单但足够好的 VCS。

检测目录复制和重命名的第一个技术障碍 - 因此这个问题。

文件数:由于这个项目的主要动机是源代码版本控制，我只需要匹配与您正在处理的项目数量相匹配的目录数量。所以，如果你正在处理两个不同的项目，那么我认为我只需要跟踪两个目录——每个项目的根目录。现在，我完全承认，在这一点上，我可能错误地描述了需求，所以也许我需要跟踪项目中的所有目录，或者甚至这些项目中的所有文件，所以让我们说，为了争论，一个典型的项目中有 1,000 个文件。所以，基本上，可能只有几个目录，或者几百个目录，或者几千个文件。重要的是，我认为 50,000 个文件将处于频谱的高端。

User duplicates the dir 'trunk' from within finder

trunk --> trunk copy

If the user renames 'trunk copy' to 'trunk copy fixed #255 per colors' the trunk dir (not the copy) would be tagged with the comment 'fixed #255 per colors'

引用文献 :

File System Event Programming

如果注册目录中的某些内容发生更改，则在启动时获得通知 - 如果大目录中的任何一个文件发生更改。它不会告诉你，我不认为，发生了什么变化。

Kernel Queues

您可以注册以获取单个文件级别的通知。您的选择(至少)如下:
注意_删除 | NOTE_WRITE |注意_EXTEND | NOTE_ATTRIB |注意_LINK |注意_重命名 | NOTE_REVOKE 这可能用于检测目录重命名(它适用于 dirs 吗？)，但显然不是 dir 副本。

稍微相关的问题 :

How to write finder plugin

谢谢，
JJ

Answer 1

最初的帖子提出了一个非常大的项目，其中包含许多未指定的功能。您以“...检测目录副本和重命名...”结尾的“扩展动机”很有帮助。

首先，您几乎用文件系统事件和内核队列的引用回答了您自己的帖子。您解雇文件夹操作是正确的，但原因是错误的。您似乎关心为大量文件夹激活 FA。这不是问题，因为它可以自动化。 FA 不起作用的原因是它们无法检测到文件重命名。此外，由于操作是 AppleScript，因此开销和并发性存在巨大问题。

你对 FS 事件是正确的:(来自 Darwin Docs )

The important point to take away is that the granularity of notifications is at a directory level. It tells you only that something in the directory has changed, but does not tell you what changed.

所以看来你只剩下内核队列了。他们什么都做。请注意，您必须聪明地使用内核队列 - 您必须知道苍蝇的名称才能监控它。因此，在创建新文件/文件夹时，您必须解释事件并打开 (O_EVTONLY) 新文件。但是，有一个问题:(更多 Darwin Docs )

If you are monitoring a large hierarchy of content, you should use file system events instead, however, because kernel queues are somewhat more complex than kernel events, and can be more resource intensive because of the additional user-kernel communication involved.

另一个回复提到 TimeMachine 使用了 FS 事件。我对此表示怀疑，因为提到了“粗粒度”。我怀疑内核“关闭文件”代码中有一个特殊的钩子(Hook)。至少，如果您想监视许多文件，这似乎是您所需要的。你考虑几个？