如何在Windows 8中使用在Mac上创build的重用软链接

你的问题是缺少一些细节，所以我将不得不猜测你的情况。 问题是：

您在文件系统上使用OS X创建了一些符号链接，现在您在访问Windows中的符号链接时遇到问题。

除非你做了一些棘手的事情，比如安装第三方文件系统驱动程序，那么Windows和OS X本身可以读取/写入的唯一文件系统是基于FAT的。 所以我猜你的情况是：

您在FAT32文件系统上使用OS X创建了一些符号链接，现在您在访问Windows中的这些符号链接时遇到问题。

假设上述情况，问题是在FAT32中没有符号链接，因为文件系统不支持它们。 OS X欺骗你，因为它“正常”。 真正发生的事情是，OS X正在创建一个ASCII文本文件，其中包含“XSym”行以及“链接”到的文件的名称，以及一些文件系统信息。 您可以通过在记事本中的Windows系统上打开您的软链接来确认这一点。 通常你会看到二进制代码，如果你打开记事本中的实际图像，而是应该看到这些假符号链接的文本。

所以你会怎么做？ 我看到了几个选项：

1. 您可以使用支持软链接的文件系统。 这可能意味着使用HFS +（OS X文件系统），这将需要您在Windows系统上安装HFS +驱动程序，以便它可以读写文件系统。 或者这可能意味着朝另一​​个方向发展，并使用NTFS（Windows文件系统），这将需要您在Mac上安装NTFS驱动程序。 请注意，最新版本的OS X可以读取NTFS文件系统，他们只是不能写入他们。

2. 您可以使用OS X正在创建的假符号链接。 这将需要编写一个解析器来解释链接或找到一个为你做这个的库。 我没有一个副本，但我相信XSym格式在“OS X内部”一书中有介绍。

3. 您可以重新思考解决问题的方法，这样就不需要使用符号链接。

如果这不能解决你的问题，那么请提供更多的细节，因为我不得不对你的情况做一些猜测。

== ==编辑

看看这里的符号链接颠覆文档。 文档的相关引用是：

版本控制符号链接

在非Windows平台上，Subversion能够对特殊类型符号链接（或“符号链接”）的文件进行版本化。 符号链接是一种文件，作为对文件系统中某个其他对象的透明引用，允许程序通过对符号链接本身执行操作来间接读写这些对象。

当一个符号链接被提交到一个Subversion版本库时，Subversion记得这个文件实际上是一个符号链接，以及符号链接“指向”的对象。当这个符号链接签出到非Windows系统上的另一个工作副本，Subversion从版本化的符号链接重建一个真正的文件系统级别的符号链接。 但是，这并不会限制Windows等系统上不支持符号链接的工作副本的可用性。 在这样的系统上，Subversion只是创建一个常规的文本文件，其内容是原始符号链接指向的路径。 虽然该文件不能用作Windows系统上的符号链接，但也不会阻止Windows用户执行其他与Subversion相关的活动。

基本上，它说的东西类似于我之前提到的，那就是符号链接在Windows系统上完全不受支持。 Subversion只是创建链接内容的文本文件，所以你可以选择自己解析这些文本文件，或者试图找到一个库来解析它们。

也许问题是在一个目录中有这么多的链接

在特定路径中最多允许有31个解析点（因此符号链接）。

也可以看看

• 编程注意事项

我知道我迟到了，但是我希望其他人可以从我的回答中受益，即使提问者可能已经很久了。

一些背景

符号链接语义在unixoid系统和Windows之间有很大不同。 如前所述，Windows使用重新分析点来实现符号链接和联结点（服务器版本上的一些重复数据删除功能似乎也使用它）。

现在，重新分析点包含额外的数据作为I / O管理器和对象管理器的提示。 本质上，基于重新分析点标记（GUID）可以确定重新分析点的类型，然后文件系统筛选器驱动程序处理详细信息。 您可以在第9章“Windows内部”或最近的Windows驱动程序工具包或MSDN中的REPARSE_GUID_DATA_BUFFER （及相关主题）下找到对此的中等详细描述。

在unixoid系统上，文件系统元数据还包含（文本文件）是符号链接的线索。 如果你使用ls -l这个线索是以前导l的形式显示的，例如：

 lrwxrwxrwx 1 user group 38 2015-10-12 11:51 

符号链接的实际内容也是特定于系统的，例如在Linux上，它们只包含目标路径。

Windows和* nix符号链接共享的是目标在创建时不需要存在。 另外在Windows上，符号链接可以指向网络位置，这是特殊的， 因为在Windows上，网络路径与本地路径不同。

可能的兼容性

假设在OSX或Linux一侧创建了一个符号链接，我们可以想象一定程度的兼容性。 如果Windows端的文件系统驱动程序现在将符号链接作为重新分析点，并且某个方（文件系统驱动程序或文件系统过滤器）将处理这些重新分析点，则可能会解释符号链接的目标路径某种方式。

然而，将正斜杠转换成反斜杠是最不关心的。

在这个答案中，我已经概述了一些不可能有意义的翻译的情况。

从本质上来说，唯一能够看到兼容性的符号链接类型是相对符号链接 。 但是，即使对于这些也是必要的，指出目标路径可能不指向在Windows端可见的文件夹层次结构之外。 也就是说，如果OSX或Linux端的符号链接驻留在 /var/www/html并指向../../../something ，则在/var是Windows上安装的卷的情况下，它变得毫无意义。

但是，如果这样的符号链接/var/www/html/foobar和指向../html1/foo/bar机会是，如果/var是在OSX或Linux上安装的卷，现在在Windows上，则相对目标路径仍然会感觉（经过诸如向前斜线等的调整）。

对于任何绝对目标路径，文件系统驱动程序或文件系统过滤器驱动程序必须获得有关如何将符号链接的源表单转换为目标表单的提示。

例如，如果符号链接指向/home/foo/bar那么/home部分可能会转换为特定的安装卷。

但是你已经可以看到这需要大量的用户干预，这也许就是为什么大多数人会认为甚至尝试一个有意义的翻译是徒劳的。

SVN可能的解决方法

一个可能的解决方法可能是使用SVN外部。 这取决于确切的情况，但是因为你使用SVN，所以他们想到了。

你可以把SVN外部看作Subversion的本地符号链接。 我用这种方式来使用它们，而且我知道其他几个人，但是我不知道这种思路和后来的用法有多广泛。

注意：外部指向的文件只在SVN 1.6中引入，所以这可能会或可能不会在您的方案中的问题。

SVN外部有几种口味 。 您可以将它们设置为文件夹或文件（文件只有1.6和更新版本）。

而外部可以指向：

1. 一个外部回购（ schema://server/path ）
2. 相对于相同的回购（ ^/path ）
3. 相对于架构（ //server/path ）或
4. 相对于父目录

您可能需要从该列表中的2或4。 不过，最有可能的是你需要4，因为文件外部必须指向同一个存储库。

长话短说

如果你的图像是在一个文件夹，如trunk/images ，你有一个文件夹的trunk/platforms/windows/images你可以在trunk/platforms/windows上设置svn:externals属性，让外部命名的images指向../../images （即外部目录），或者假设你想在trunk/platforms/windows/images下面使用不同的层次结构或不同的名字，你可以像这样创建文件外部结构（ images子目录必须存在于WC中）：

 cd trunk/platforms/windows svn propedit svn:externals images 

并添加像这样的个人外部：

 ../../../images/filename.jpeg other-filename.jpeg 

请注意，目标目录需要存在于存储库和工作副本中，所以对于外部像这样：

 ../../../images/filename.jpeg foo/other-filename.jpeg 

子目录trunk/platforms/windows/images/foo 必须存在。

更新您的工作副本将导致这些外部工作副本中显示为版本化文件。 所以它们是SVN中存在的一种符号链接，在工作副本中显示为正确的文件，这意味着所有平台都可以平等地处理它们。