I need access to the lchown() system call on about three different unix platforms.  The source code appears to check for the existence of such a system call, but how do I go about using it?

thanks...

--jason

--

  JB> I need access to the lchown() system call on about three different
  JB> unix platforms.  The source code appears to check for the
  JB> existence of such a system call, but how do I go about using it?

why do you need to call lchown? it is almost a useless call. the owner
(or anyone with write permission) of the directory it is in can delete
it and recreate it. the ownership of a symlink never affects who can use
it so changing it means little.

uri

If you need to get a hold of specific system calls though, use XS or
the syscall facility to call it directly.

[lines wrapped for post]

$ pwd
/spare/SRC/perl-5.6.1
$ find . -name \*.h -o -name \*.c | xargs grep -i lchown
./doio.c:XXX Should we make lchown() directly available from perl?
./doio.c:For now, we'll let Configure test for HAS_LCHOWN, but do
./vos/config.alpha.h:/* HAS_LCHOWN:
./vos/config.alpha.h: * This symbol, if defined, indicates that the
    lchown routine is
./vos/config.alpha.h:/*#define HAS_LCHOWN               /**/
./vos/config.ga.h:/* HAS_LCHOWN:
./vos/config.ga.h: *    This symbol, if defined, indicates that the
    lchown routine is
./vos/config.ga.h:/*#define HAS_LCHOWN          /**/

Inspection of other files leads me to believe that Configure does test
for lchown and appropriate configuration variables get set, but that
nothing really happens anywhere to act on this. There's a note in
doio.c, which has been there for a while, that leads me to
believe that the tests in Configure were put there specifically
for a possible future extension that would make lchown available
in Perl:

/*
XXX Should we make lchown() directly available from perl?
For now, we'll let Configure test for HAS_LCHOWN, but do
nothing in the core.
    --AD  5/1998
*/

Each symlink counts against the UID's inode limit.  Symlinks with
target names longer than 59 bytes don't fit inside the inode, causing
a disk block to be allocated and charged against the block quota.
        -Joe

First, thank you for replying so quickly.

I am changing the uids and gids of all of my files on all of my systems.  This crosses about 15 different machines running solaris 2.x, freebsd, linux, and hp-ux.  I also am using clearcase so the targets may not actually be available outside of a clearcase view, and chown chokes on there being no target.  Since the current chown call dereferences a symlink and changes the target's uid/gid, this could be disastrous if the wrong uid is applied to a target file.  

Alternately, running in a shell script using the "chown" program also has problems.  These problems start with filenames having spaces, and move up to filenames having shell metacharacters.

Now while I can get around this, (and will), it begs the question since the source configuration checks if the lchown() call exists.  :)

Oh, I just re-read your response.  you are correct about the symlink's permissions not affecting who can access files.  I expect to be getting a lot of queries about "why isn't this symlink owned by me".  Thus, I am really working to reduce the "pita" factor (pain in the a__).

--jason

On Wed, 28 Nov 2001 22:43:40 GMT

Original advice still holds: if you want a specific system call for
sure, use syscall or XS.

On Wed, 28 Nov 2001 16:09:01 -0800,

It would be much better to just skip symlinks alltogether, and limit
yourself to plain files and directories:

$ find /home/user -type f -o -type d | xargs chown user

This also gets around the problem of symlinks pointing to nothing.

$ CHOWN_OPTIONS="-some_platform_specific_option"
$ find /home/user -type l | xargs chown $CHOWN_OPTIONS

I think this could quite easily be done with a simple shell script,
unless there's more that you haven't told us yet.

   However, if you don't use lchown you have to check for yourself
whether what you are about to change is a symlink (which comes with the
usual race-condition associated with such things).  When you are running
an admin script you might well wish to chown the entries in "this"
directory but not what any symlinks point to.

   This is also why the chown command has a -h option.