On Sun, Dec 10, 2017 at 3:24 PM, <webmas...@bennettconstruction.us> wrote: ... > > > > > dump > > > > I had to move /usr/local to a bigger partition. growfs, > > > > etc. I kept the /usr/local untouched and then dumped it > > > > to the new partition, expecting a true duplication. > > > > Nope. > > > > It changed all of the program symlinks permissions. > > > > You do know that the mode of a symlink has *no* effect on how the kernel > > processes it, don't you? As far as the kernel is concerned, you can do > > the exact same operations on a mode 0 symlink as on a mode 777 symlink. > > No, I didn't know. I have had lots of problems when ownership changes > with the symlinks, so I wrote I program to delete and restore them with the > proper owners. Thanks for letting me know. I can delete the files I had > left on the old > partition. >
Wait, you previously said your problem was with symlinks *permissions* but now you're saying *ownership*! I can confirm that restore(8) didn't preserve the permissions (thus the patch I sent), but as long as you ran it with sufficient privilege it should have always restored symlink *ownership*. Was that a slip of the tongue/fingers? (Symlink ownership doesn't affect the ability to follow the symlink; it only matters for directory-entry/inode level operations, such as deciding who can remove a symlink from a mode 1777 directory like /tmp and who can change the group or perms on the symlink. AFAIK, the _group_ of a symlink is never checked.) Philip Guenther
