符号链接在共享到 Windows 或 Linux (smb) 时有效，但在共享到 Mac（afp 或 smb）时损坏
在 Mac 上，我有一个共享文件夹 ~\Documents。有两个子文件夹：Data 和 Data_2011，前者包含过去几年的文件文件夹，后者包含指向 Data 文件夹中自 2011 年 1 月 1 日以来更新的文件夹的符号链接。这些链接是使用标准创建的ln -s 命令。
当我在 Windows 计算机上安装共享文档文件夹时，链接有效。当我使用 smb 在 Linux 上挂载时，链接有效。当我直接在托管 Mac 上使用这些链接时，它们可以正常工作。但是，当我从远程 Mac 装载 Documents 文件夹时，软链接被破坏。需要明确的是，我通过转到 Finder > 来挂载文档文件夹。连接到服务器> afp://xxx.xxx.xx.xx/ 或 smb://xxx.xxx.xx.xx/Documents
对于如何在共享到远程 Mac 时使这些软链接正常工作有什么想法吗？
-思博
On a Mac, I have a shared folder, ~\Documents. There are two subfolders, Data and Data_2011, the former containing folders of files from the last several years, and the latter containing symbolic links to the folders in the Data folder that have been updated since Jan 1 2011. The links were created with the standard ln -s command.
When I mount the shared Documents folder on a Windows computer, the links work. When I mount on Linux using smb, the links work. When I use these links directly on the hosting Mac, they work. However, when I mount the Documents folder from a remote Mac, the soft links are broken. To be clear, I mount the Documents folder by going to Finder > Connect to Server > afp://xxx.xxx.xx.xx/ or smb://xxx.xxx.xx.xx/Documents
Any ideas for how to get these soft links to work when shared to a remote Mac?
-Sibo
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
Mac OS 文件共享将符号链接公开为实际符号链接。
如果我使用 AFP 或 SMB 将一台 Mac 连接到另一台 Mac，我可以确认这一点。
请注意，符号链接是由客户端解析的——即使在非文件共享的情况下，这也意味着符号链接中的相对路径可能很棘手，在这种涉及网络文件共享的情况下，这意味着客户端计算机需要能够查看目标文件（目标文件也必须位于共享并挂载的文件夹中），并且路径需要相同。
例如，如果我在主目录中创建一个名为“foo”的文本文件，然后执行“ln -s foo symlink”来创建一个名为 symlink 的链接，然后从第二台计算机挂载该主目录并执行“ls - l”它显示为“symlink@ -> foo”，如果我捕获该文件，我可以读取它。但是，如果我将符号链接创建为“ln -s /Users/matt/foo symlink”，那么在第二台计算机上 ls -l 将其显示为“symlink@ -> /Users/matt/foo”，并且 cat 说“cat ：符号链接：没有这样的文件或目录”。这是因为在第二台计算机上， /Users/matt 是一个本地主目录，不包含名为 foo 的文件（如果包含，解析符号链接的任何内容都会看到本地 foo，而不是从第一台计算机共享的 foo） 。
所以基本上：您可以使用“ls -l”来查看符号链接指向的位置，并注意客户端计算机将解析符号链接并尝试打开具有该名称的任何文件，这可能是也可能不是您所期望的。
（您的测试在 Linux 计算机而不是 Mac 上运行的原因可能是 Linux 计算机安装了更多网络共享或具有不同的名称，这样符号链接目标名称在 Linux 计算机上是有效的文件名，但在 Mac 上则不是。 ）
Mac OS file sharing exposes symbolic links as actual symbolic links.
If I connect one Mac to another, using either AFP or SMB, I can confirm this.
Note that symbolic links are resolved by the client -- even in a non-file-sharing case this means relative paths in symbolic links can be tricky, and in this case involving network file sharing, it means the client computer needs to be able to see the target file (the target file must also be in a folder that's shared and mounted), and the path needs to be the same.
For example, if I create a text file named "foo" in my home directory, then do "ln -s foo symlink" to create a link to it named symlink, then mount that home directory from a second computer and do "ls -l" it's shown as "symlink@ -> foo", and if I cat the file I can read it. But if I create the symlink as "ln -s /Users/matt/foo symlink", then on the second computer ls -l shows it as "symlink@ -> /Users/matt/foo", and cat says "cat: symlink: No such file or directory". That's because on the second computer, /Users/matt is a local home directory that doesn't contain a file named foo (and if it did, anything resolving the symlink would see the local foo, not the foo shared from the first computer).
So basically: you can use "ls -l" to see where the symlink points, and note that the client computer will resolve the symlink and try to open whatever file has that name, which may or may not be what you expected.
(Probably the reason that your test worked from your Linux machine and not your Mac is that the Linux machine has more network shares mounted or with different names, such that the symlink target name was a valid filename on the Linux machine but not the Mac.)