Summary: pkgmk doesn't recognize hard links

From: Spurgeon, John P <>
Date: Thu Mar 14 2002 - 14:23:54 EST
I received replies from:
Gert-Jan Hagenaars []
Andrew J Caines []
Fabrice Guerini []
Matthew Stier [] (Jason)

Ed and Matthew both identified the root cause of my problem (Jason was
partially correct). In my original message I said my prototype file
looks like this:

i pkginfo
f none /etc/init.d/informix=/etc/init.d/informix 0744 informix informix
f none /etc/init.d/S94informix=/etc/rc2.d/S94informix 0744 informix informix

In order for the S94informix file to be recognized as a hard link, the line
should have looked like this:

l none /etc/init.d/S94informix=/etc/init.d/informix 0744 informix informix

In my original message I used the following command to add the line to the
prototype file:

pkgproto /etc/rc2.d/informix=/etc/rc2.d/informix >> prototype

I incorrectly assumed that pkgproto could tell that the file was a hardlink
and would create the appropriate entry in the prototype file. Matthew
remarked, "pkgproto is capable of detecting hard links within a single run.
However, your example has two runs of one file each." I tried this, and I
believe Matthew is correct. The moral of the story is: Be carefull how you
construct your prototype file when dealing with hard links.

A few people commented that piping the output of a find command to the
pkgproto command may be a "better" way to build the prototype file. In my
experience, this is sometimes the case, but it is situational. In the end,
all that matters is that the prototype file is set up correctly, and mine

Regarding one of my proposed work arounds, Ed said, "Creating links with
a postinstall is not good, because then they won't be removed by pkgrm (and
with a startup script, that can be messy)". I agree that you have to be
here. If you want to take the plunge and do something in the postinstall
it's probably a good idea to add corresponding logic to the preremove

Several people had opionions about my P.S. regarding hard links vs. symbolic
links to /etc/init.d/. The replies were interesting. I still can't tell
one type of link is really better than the other. Again, I suppose it's
situational. Here's what folks had to say:

Ed wrote:

I've also always used hardlinks in rcx.d but there are definitely a few
in some of them. I guess this might just be a hangover frmo the way things
always done.

Gert-Jan wrote:

Just on a personal note: I've _always_ used soft links in /etc/rc2.d
(and the rest).  Simply because there's always a couple of newbie system
administrators around, and I want to make sure that they know where the
"real" scripts live.  So my policy has always been: there are _only_
soft links in the rc*d directories, all the real stuff lives in

Andrew wrote:

There are at least two common agruments against symlinks.

The first is that they are a dirty hack created for linking across
filesystems and that symlinking within a filesystem is symptomatic of
ignorance. Since /etc must be in the root filesystem, there is no need for

The second is that that there is a performace penalty. A symlink is the
equivalent of a sign on the door saying "No-one home. Try over there".
This means that the number file tree traversals and other things is
doubled and the various caches can't be properly or efficiently used. For
startup, this isn't as big and issue as, for example, web content.

Fabrice wrote:

Well, IMHO, for what it's worth, Sun's decision to use hard links between 
/etc/rc*.d and /etc/init.d is a poor one. It makes it difficult for you to 
determine what each start-up file is linked to. In addition, it forces you 
to have the start-up file and its link on the same filesystem, which you 
may or may not want to do. Any time I create a new start-up file, I use 
symbolic links instead. This has the advantage, if I change, say, 
/etc/init.d/sendmail with an editor which does not conserve the inode (or 
by using the "cp" and "mv" commands), my link is still good, where with a 
hard link, I could make changes until I'm blue in the face and would wonder 
why they never seem to take effect at boot time.
sunmanagers mailing list
Received on Thu Mar 14 13:25:21 2002

This archive was generated by hypermail 2.1.8 : Thu Mar 03 2016 - 06:42:37 EST