>Curiously this tradition of > "file goes in /etc/init.d, SOFT linked in > /etc/rc?.d" is not followed by the scripts that > ship with Nevada!? Instead, hard links are used!!!
I certainly hadn't mentioned such a "tradition" - I said "link or symlink". Looking in /var/sadm/install/contents (installed files from packages) on a Solaris 8 system, every Sun-supplied file I see in /etc/rc*.d (over a hundred) is hard linked to /etc/init.d. There is exactly _one_ file in there symlinked into its /etc/rc*.d location, and that's a locally created package. (there are also a fair number of local non-packaged scripts, mostly symlinked) As far as that goes, I could agree that the symlink is a better move - more informative at a glance. But either will cause _someone_ problems - there are editors that rewrite a file (same inode) - they don't break hard links. There are other editors that rename to .bak or whatever and replace a file, they break hard links - and unless they check and follow the symlink themselves (some may have been fixed up to do that), they break symlinks too, unless you give them the real name rather than the symlink. Hard links are faster and may use less space, depending on how symlinks of the length in question are implemented (even a short symlink stored in an inode rather than in a data block still takes an extra inode). Usually that's negligible, but when people want reasonably complete distros shrunk down to mere CDs rather than DVDs, _and_ want fastest possible installation, etc - that sort of thing probably adds up. And some ancestral systems on the SysV side didn't have symlinks (SVR3 and earlier, IIRC), but used a similar rc layout. Or so I would guess the rationale behind the long history of using _hard_links_ for the purpose came about. Today, I question whether there's any serious argument that could be made against using symlinks...perhaps there just wasn't compelling reason to change. This message posted from opensolaris.org _______________________________________________ opensolaris-help mailing list [email protected]
