Rackspace的云网站有很多愚蠢的限制。 例如，没有SSH（进出），没有shell，没有RSYNC等（甚至通过cron）。
最近我了解到，您无法可靠地在Cloud Sites中使用符号链接。 显然这是因为你的网站的绝对path随时都可能改变，因为它是在多个磁盘/服务器之间分离的共享主机环境。 我想不同的帐户的网站从磁盘到磁盘每当Rackspace决定。 据说为了全面提高效率。
因此，在与Rackspace技术部门交谈后，他表示不能保证符号链接始终有效。 显然这是因为如果你有一个符号链接，使用这样的绝对path：
//mnt/disk-34566/home/user34566/files/sites/www.mysite.com/mydir 如果你的文件被移动到不同的磁盘上（或者他们做了什么），那么绝对path将会不同，现在链接将被打破。 这就说得通了。
接下来，我询问Rackspace技术是否相对path符号链接可靠。 所以如果我有以下的链接：
files/sites/www.mysite.com/mylink --> ../www.myothersite.com/anotherdir
你可以看到符号链接只是指向附近目录的子目录。 他说他们不能保证即使是那些也会一直工作。 由于它使用一个相对path到另一个附近的目录，我不知道它是如何能够从Rackspace将做的事情。 相对符号链接不知何故依靠下面的绝对path？ 还是Rackspace使用一些奇怪的自定义文件系统，他们将从绝对path的变化中断？
这似乎是一个相对path符号链接将罚款，只会打破如果用户做了一些搞砸的目录涉及。 但是，当技术人员说，他们“ 不正式支持任何forms的符号链接 ”，这使我犹豫在云端网站的大型商业网站使用它们。
任何有Rackspace经验的人都可以就这个话题给出意见吗？
我不是在Rackspace，但曾经为托pipe服务提供商工作，我可以给你一个普遍的build议：
如果你的提供者说了一些“我们不能保证X会起作用”的东西，而且你select这么做，那你就不在任何人的支持你的能力范围之内了。
如果有效，“嘿，太好了！我们真的为你高兴！”
如果有一天它停止工作 – “不要向我们哭，我们告诉过你不要这样做！” （这意味着你自己来修复破损，否则你将要支付你的提供者的费用$）。
从技术angular度来看，我不明白为什么相对path符号链接会中断，前提是您始终在支持符号链接的文件系统上。 有一天，您的云网站可能会奇迹般地迁移到Flippy的Freaky Fantasy Filesystem，它不支持符号链接的概念 – 这就是Cloud的本质。