Discussion:
Symlinks in OS X (10.4.1)
d***@gmx.org
2007-10-13 18:56:23 UTC
Permalink
Hi,

is there a way to ignore the permissions for symlinks but compare the permissions for regular files and change them accordingly?

The problem is that using OS X every time I run rsync it tries to update the permissions for the symlinks but the changes are not made since OS X has no support for symlink permissions. Therefore it would like to somehow ignore symlink permissions.


Thanks,
Mario
Wesley W. Terpstra
2007-10-14 15:08:13 UTC
Permalink
Post by d***@gmx.org
since OS X has no support for symlink permissions
Actually, this isn't quite true. osx has no lchmod, but if you set a
umask before creating the link, the permissions are set. So, as
opposed to ignoring the permissions, perhaps we should teach rsync
how to set them. I'll probably look at this as soon as I'm done
writing a patch for preserving the creation date.
d***@gmx.org
2007-10-14 20:05:36 UTC
Permalink
Post by Wesley W. Terpstra
Actually, this isn't quite true. osx has no lchmod, but if you set a
umask before creating the link, the permissions are set. So, as
opposed to ignoring the permissions, perhaps we should teach rsync
how to set them. I'll probably look at this as soon as I'm done
writing a patch for preserving the creation date.
Thank you for the reply!
I know about the missing lchmod in OS X, but I don't really see a need for
it. Why can't a symlink just have a default permission of 0777? In case the
symlink gets dereferenced the target's permissions have to be considered
anyway. Of course it is cleaner to have them set properly, but if they are
just ignored it won't hurt either.

Regards,
Mario
Wesley W. Terpstra
2007-10-15 10:18:39 UTC
Permalink
Post by d***@gmx.org
Post by Wesley W. Terpstra
Actually, this isn't quite true. osx has no lchmod, but if you set a
umask before creating the link, the permissions are set. So, as
opposed to ignoring the permissions, perhaps we should teach rsync
how to set them. I'll probably look at this as soon as I'm done
writing a patch for preserving the creation date.
I know about the missing lchmod in OS X, but I don't really see a need for
it. Why can't a symlink just have a default permission of 0777? In case the
symlink gets dereferenced the target's permissions have to be
considered
anyway. Of course it is cleaner to have them set properly, but if they are
just ignored it won't hurt either.
I believe in osx the symlink permissions have meaning (as opposed to
linux). Eg:

-rwxrwxrwx bar
----r--r-- foo -> bar

In linux, 'cat foo' will work, in osx, it will fail. So, this meta-
data has meaning, and to just replace it with 0777 will not give you
a functionally equal copy.
Wayne Davison
2007-10-15 18:19:16 UTC
Permalink
Post by Wesley W. Terpstra
I believe in osx the symlink permissions have meaning (as opposed to
linux).
Is there a system call that allows their permissions to be changed
after they've been created? (Since lchmod is lacking.)

..wayne..
Matt McCutchen
2007-10-16 02:21:35 UTC
Permalink
Post by Wayne Davison
Is there a system call that allows their permissions to be changed
after they've been created? (Since lchmod is lacking.)
I don't think so, but as Wesley hinted, one can effectively change a
symlink's permissions by deleting it, setting the umask appropriately,
and recreating it. I think this behavior is useful enough to be
provided by a distributed patch. It does break hard links; are there
any other caveats?

Matt
Simo Sorce
2007-10-16 13:23:14 UTC
Permalink
Post by Matt McCutchen
Post by Wayne Davison
Is there a system call that allows their permissions to be changed
after they've been created? (Since lchmod is lacking.)
I don't think so, but as Wesley hinted, one can effectively change a
symlink's permissions by deleting it, setting the umask appropriately,
and recreating it. I think this behavior is useful enough to be
provided by a distributed patch. It does break hard links; are there
any other caveats?
Deleting the symlink, means the link is not present for an undetermined
period, doesn't seem a really clean way to just change permissions.

Simo.
Wesley W. Terpstra
2007-10-16 04:37:09 UTC
Permalink
Post by Wayne Davison
Post by Wesley W. Terpstra
I believe in osx the symlink permissions have meaning (as opposed to
linux).
Is there a system call that allows their permissions to be changed
after they've been created? (Since lchmod is lacking.)
I was about to say no, but then I saw this:
setattrlist + ATTR_CMN_ACCESSMASK

I'll check tomorrow if one can write lchmod for osx using this.
Wayne Davison
2007-10-16 16:11:40 UTC
Permalink
Someone with an intel mac should test this to check the uint32_t works
there too (I have a powerpc).
It worked fine for a simple test.

The latest CVS code now has your lchmod() alternative if setattrlist()
is around. Thanks! Now we'll see if any unexpected systems are
affected by this change (I'm not expecting any, though).

..wayne..

Wesley W. Terpstra
2007-10-16 04:37:09 UTC
Permalink
Post by Wayne Davison
Post by Wesley W. Terpstra
I believe in osx the symlink permissions have meaning (as opposed to
linux).
Is there a system call that allows their permissions to be changed
after they've been created? (Since lchmod is lacking.)
I was about to say no, but then I saw this:
setattrlist + ATTR_CMN_ACCESSMASK

I'll check tomorrow if one can write lchmod for osx using this.
Wayne Davison
2007-10-14 23:57:31 UTC
Permalink
Post by d***@gmx.org
is there a way to ignore the permissions for symlinks but compare the
permissions for regular files and change them accordingly?
That should be the default for any system that doesn't have lchmod().

..wayne..
Wayne Davison
2007-10-15 00:13:10 UTC
Permalink
Post by Wayne Davison
Post by d***@gmx.org
is there a way to ignore the permissions for symlinks but compare the
permissions for regular files and change them accordingly?
That should be the default for any system that doesn't have lchmod().
Aha, I see the problem. Rsync doesn't try to set the permissions, but
it does list the permissions as differing in the itemized output. I'll
fix that.

..wayne..
Continue reading on narkive:
Loading...