Conference turris::digital_unix

9171.0. "Wondering on setld" by REQUE::CHOI (Yung Choi (ZKO2-2/R80 DTN:381-2295)) Thu Mar 13 1997 18:29

Hi;

    The attached has been posted on the SETLD notes for the last few days,
    but there are no replies...

    Any help will be appreciated.  Thank you.			- Yung
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        <<< HUMANE::DISK$RZ29:[NOTES$LIBRARY]SETLD-ULTRIX-LPS.NOTE;1 >>>
 -< The setld and ULTRIX layered product installation/integration conference >-
================================================================================
Note 358.0               setld question for Digital UNIX              No replies
REQUE::CHOI "Yung Choi (ZKO2-2/R80 DTN:381-2295)"    32 lines  11-MAR-1997 15:22
--------------------------------------------------------------------------------
    A question about setld on Digital UNIX; it is for the file protection
    on the kits.

    In my kit builder,

	# cp -p my_file ./usr/opt/MYKIT300/my_file
	# chmod 744 ./usr/opt/MYKIT300/my_file
	# ln -s ./usr/opt/MYKIT300/my_file my_file

    Then ./usr/opt/MYKIT300/my_file gets different protection for different
    OS version of Digital UNIX.

	Digital UNIX 3.0	rwxr--r--	./usr/opt/MYKIT300/my_file
	Digital UNIX 3.2C	rwxrwxrwx	./usr/opt/MYKIT300/my_file
	Digital UNIX 4.0	rwxr--r--	./usr/opt/MYKIT300/my_file

    The linked my_file gets lrwxrwxrwx for all OS versions, and this is what
    expected. It is 100744 on the inv file for V3.0 and V4.0, but it is
    100777 for V3.2C.

    The problem is why 3.2C sets the original file's protection different
    from what is asked?

    Is there any way to make 3.2C sets proper protection?

    Thank you.						- Yung

PS: We are now upgrading 3.0 machine to 4.0 and our product should suport
    3.2C. So far the kit has been built by 3.0 machine, but after it is
    upgraded, 3.2C must be used.

I answered this in the SETLD-ULTRIX-LPS conference but that seems to have gone
away.

First off if you build your product on a V4.0 system it will not run on a V3.x
system because the changes in libc.so.  You have a better chance if you link
your application statically but no guarantee they will work on a previous
release.

This sounds like a bug in /usr/lbin/invcutter because you shouldn't be getting
the wrong mode settings from your indicated commands.  To verify what the
invcutter programs is you can do the following command:

echo "0\t./usr/opt/MYKIT300/myfile\tMYKIT300" | /usr/lbin/invcutter

If this doesn't report the correct mode then this would confirm the bug in
how invcutter is generating its records.

If you don't see this mode change until you load the subset, this is probably
a tar problem with the directory not existing before the file is created.

Sean

It has just moved to HUMANE::SETLD-ULTRIX-LPS