Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

savannah: ownership is not preserved when copying symlinks #17

Open
mc-butler opened this issue Dec 25, 2008 · 12 comments
Open

savannah: ownership is not preserved when copying symlinks #17

mc-butler opened this issue Dec 25, 2008 · 12 comments
Labels
area: core Issues not related to a specific subsystem prio: medium Has the potential to affect progress

Comments

@mc-butler
Copy link

Important

This issue was migrated from Trac:

Origin https://midnight-commander.org/ticket/17
Reporter slavazanko (@slavaz)
Mentions dgunchev@….com, gotar@….pl, howaboutsynergy@….me

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

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

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. 

Comment 1 by Pavel Tsekov <ptsekov> at Thu 07 Jul 2005 12:33:11 PM UTC:

Confirmed. I'll be working on this.

Comment 2 by Andrew V. Samoilov <sav> at Sat 16 Jul 2005 09:29:22 AM UTC:

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.

Comment 3 by Pavel Tsekov <ptsekov> at Sat 16 Jul 2005 01:30:48 PM UTC:

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().

Comment 4 by Andrew V. Samoilov <sav> at Mon 01 Aug 2005 02:40:32 PM UTC:

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().

Comment 5 by Pavel Tsekov <ptsekov> at Mon 01 Aug 2005 02:55:55 PM UTC:

What happens if you want to work on the target of the symlink and 
not on the link itself ? readlink() followed by lchown () ?

Comment 6 by Andrew V. Samoilov <sav> at Mon 01 Aug 2005 04:55:59 PM UTC:

Well, in that case I will use chown command. I heard complains 
about current behaviour and I found these complains reasonable.

Comment 7 by Pavel Tsekov <ptsekov> at Tue 02 Aug 2005 07:51:51 AM UTC:

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 ?
@mc-butler
Copy link
Author

Changed by winnie (@winnieXY) on Jan 20, 2009 at 6:22 UTC (comment 1)

  • Milestone set to 4.6.3
  • Version set to 4.6.1

Moving this to 4.6.3

@mc-butler
Copy link
Author

Changed by angel_il (@ilia-maslakov) on Mar 5, 2009 at 11:18 UTC (comment 2)

  • Resolution set to wontfix
  • Status changed from new to closed

At the utility 'cp' similar behaviour.

@mc-butler
Copy link
Author

Changed by mr700 (dgunchev@….com) on Mar 6, 2009 at 21:40 UTC (comment 2.3)

  • Resolution wontfix deleted
  • Cc set to dgunchev@….com
  • Status changed from closed to reopened

Replying to angel_il:

At the utility 'cp' similar behaviour.

What do you mean? Plain 'cp' by default does not preserve anything, but 'cp -a' or even only 'cp --preserve=ownership' does preserve symlink ownership.

Since mc by default preserves file/directory ownership (and I can not find option not to) I think preserving symlink ownership also is to be expected... I thought it does preserve this a few moments ago. Please clarify.

@mc-butler
Copy link
Author

Changed by andrew_b (@aborodin) on Mar 7, 2009 at 7:00 UTC (comment 3.4)

Replying to mr700:

Replying to angel_il:

At the utility 'cp' similar behaviour.

What do you mean?

[andrew@myhost tmp]$ touch a
[andrew@myhost tmp]$ ln -s a link_a
[andrew@myhost tmp]$ sudo cp -d link_a link_root_a 
[andrew@myhost tmp]$ ls -l
total 0
-rw-r--r-- 1 andrew andrew 0 Мар  7 09:23 a
lrwxrwxrwx 1 andrew andrew 1 Мар  7 09:23 link_a -> a
lrwxrwxrwx 1 root   root   1 Мар  7 09:23 link_root_a -> a

@mc-butler
Copy link
Author

Changed by styx (@styx) on Mar 9, 2009 at 12:29 UTC (comment 5)

  • Version 4.6.1 deleted
  • Milestone changed from 4.6.2.1 to 4.6.3

@mc-butler
Copy link
Author

Changed by slavazanko (@slavaz) on May 8, 2009 at 13:21 UTC (comment 6)

  • Milestone changed from 4.6.3 to VFS Standardisation

@mc-butler
Copy link
Author

Changed by andrew_b (@aborodin) on Oct 2, 2011 at 6:40 UTC (comment 7)

  • Branch state set to no branch
  • Version set to master
  • Milestone changed from 4.8 to Future Releases

@mc-butler
Copy link
Author

Changed by andrew_b (@aborodin) on Oct 2, 2011 at 6:41 UTC (comment 8)

  • Component changed from mc-vfs to mc-core

@mc-butler
Copy link
Author

Changed by gotar (gotar@….pl) on Oct 10, 2011 at 10:39 UTC (comment 9)

  • Cc changed from dgunchev@….com to dgunchev@….com, gotar@….pl

@mc-butler
Copy link
Author

Changed by ossi (@ossilator) on Jan 11, 2014 at 15:41 UTC (comment 10)

  • Description edited

@mc-butler
Copy link
Author

Changed by howaboutsynergy on May 6, 2019 at 9:22 UTC (comment 11)

  • Cc changed from dgunchev@….com, gotar@….pl to dgunchev@….com, gotar@….pl, howaboutsynergy@….me

@mc-butler
Copy link
Author

Changed by zaytsev (@zyv) on Feb 21, 2025 at 7:51 UTC (comment 12)

Ticket #2615 has been marked as a duplicate of this ticket.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: core Issues not related to a specific subsystem prio: medium Has the potential to affect progress
Development

No branches or pull requests

1 participant