savannah: ownership is not preserved when copying symlinks

[slavazanko]

Original: ​http://savannah.gnu.org/bugs/?13432

Submitted by:	None	Submitted on:	Fri 17 Jun 2005 10:35:17 AM UTC
Category:	Core	Severity:	3 - Normal
Status:	Confirmed	Privacy:	Public
Assigned to:	Andrew V. Samoilov <sav>	Open/Closed:	Open
Release:	current (CVS or snapshot)	Operating System:	All

Discussion:

Tue 02 Aug 2005 07:51:51 AM UTC, comment #7:

I also think that those complaints are reasonable, but I don't 
understand what this has to do with anything ?! :)

So far, if I've read the discussion correctly, I've understand that 
you also agree that both lchown() and chown() have to be used - 
depending on the task that has to be performed. So do you still 
think mc_lchown() is wrong ? If so - why do you think so ?
	Pavel Tsekov <ptsekov>
Project Administrator
Mon 01 Aug 2005 04:55:59 PM UTC, comment #6:

Well, in that case I will use chown command. I heard complains 
about current behaviour and I found these complains reasonable.
	Andrew V. Samoilov <sav>
Project MemberIn charge of this item.
Mon 01 Aug 2005 02:55:55 PM UTC, comment #5:

What happens if you want to work on the target of the symlink and 
not on the link itself ? readlink() followed by lchown () ?
	Pavel Tsekov <ptsekov>
Project Administrator
Mon 01 Aug 2005 02:40:32 PM UTC, comment #4:

IMHO it's wrong idea to introduce mc_lchown().
Also if local_chown() will use lchown() we will fix bug with C-x O 
for symlinks. Now it change ownership for target of symlink.
We can call mc_chown() after make_symlink().
	Andrew V. Samoilov <sav>
Project MemberIn charge of this item.
Sat 16 Jul 2005 01:30:48 PM UTC, comment #3:

Maybe we should keep the chown() call in local_chown() and 
introduce a new function called local_lchown() ? Then we use the 
appropriate call based on the value of 'follow Links' ? In any case 
currently MC doesn't support changing the ownership of the link 
when the link is copied:

if (S_ISLNK (sb.st_mode)) {
int retval;

retval = make_symlink (ctx, src_path, dst_path);
return retval;
}

This is the block of code dealing with symlinks in copy_file_file().
	Pavel Tsekov <ptsekov>
Project Administrator
Sat 16 Jul 2005 09:29:22 AM UTC, comment #2:

man 2 chown
In versions of Linux prior to 2.1.81 (and distinct from
2.1.46), chown did not follow symbolic links. Since Linux
2.1.81, chown does follow symbolic links, and there is a
new system call lchown that does not follow symbolic
links. Since Linux 2.1.86, this new call (that has the
same semantics as the old chown) has got the same syscall
number, and chown got the newly introduced number.

So we need to check one more function in configure and use lchown()
insteod of chown() in the vfs/local.c if HAVE_LCHONW.
	Andrew V. Samoilov <sav>
Project MemberIn charge of this item.
Thu 07 Jul 2005 12:33:11 PM UTC, comment #1:

Confirmed. I'll be working on this.
	Pavel Tsekov <ptsekov>
Project Administrator
Fri 17 Jun 2005 10:35:17 AM UTC, original submission:

(More info on: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=314387 )

create a symlinks as a user:

timj@birgrave:bash</tmp>$ ln -s cycle cycle
timj@birgrave:bash</tmp>$ ls -al cycle
lrwxrwxrwx 1 timj timj 5 Jun 16 02:41 cycle -> cycle

copy the symlink with mc as root from cycle to loop:

root@birgrave:bash</tmp># ls -al cycle loop
lrwxrwxrwx 1 timj timj 5 Jun 16 02:41 cycle -> cycle
lrwxrwxrwx 1 root root 5 Jun 16 02:41 loop -> cycle

ownership isn't preserved here, loop should also be owned by
timj.timj as it works with files.