Norman,
There's nothing wrong with a short name symlink to your cell's fully qualified path per se, but it's incredibly difficult to keep it from creeping into places is shouldn't be: hard-coded paths in package builds, scripts, documentation and services that might eventually be available to -- but broken for -- people coming in from foreign cells. If you don't believe me, and your cell has been up for any length of time (like since before breakfast), try deleting that link for a day and see how much stuff quits working. That's what you're going to run into when your visit another site and say to your new friends there "Let me show you how we do thus-n-such in our cell", authenticate to your cell, cd there, and try to run something. Been there, got the t-shirt. It doesn't make for a good demo.
--
[EMAIL PROTECTED] (who first posted the line below that Jim Rees replied to, not that I'm proud of it. Ugh, on the contrary.)
Norman P. B. Joseph wrote:
Excuse me for being dense, (and I was in one of those Transarc training classes back in the day), but what's the harm in that symbolic link?
-norm
On Wed, 2004-10-27 at 11:34, Mitch Collinsworth wrote:
On Wed, 27 Oct 2004, Jim Rees wrote:
'/afs/isis' is a symbolic link, leading to a mount point for volume 'root.cell'.
So you broke one of the most important features of afs, the global name space. Why?
Huh? Transarc trainers specifically taught to do exactly this 15 years ago. The recommendation was there to still use the FQDN in all symlinks, scripts, etc. But it was recommended to have it for typing ease. Remember /afs/tr ?
-Mitch _______________________________________________ OpenAFS-info mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo/openafs-info
_______________________________________________ OpenAFS-info mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo/openafs-info
