Ticket #17 (reopened defect)
savannah: ownership is not preserved when copying symlinks
Reported by: | slavazanko | Owned by: | |
---|---|---|---|
Priority: | major | Milestone: | Future Releases |
Component: | mc-core | Version: | master |
Keywords: | Cc: | dgunchev@…, gotar@…, howaboutsynergy@… | |
Blocked By: | Blocking: | ||
Branch state: | no branch | Votes for changeset: |
Description (last modified by ossi) (diff)
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 |
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 ?
Change History
comment:2 follow-up: ↓ 3 Changed 16 years ago by angel_il
- Status changed from new to closed
- Resolution set to wontfix
At the utility 'cp' similar behaviour.
comment:3 in reply to: ↑ 2 ; follow-up: ↓ 4 Changed 16 years ago by mr700
- Status changed from closed to reopened
- Cc dgunchev@… added
- Resolution wontfix deleted
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.
comment:4 in reply to: ↑ 3 Changed 16 years ago by andrew_b
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
comment:5 Changed 16 years ago by styx
- Version 4.6.1 deleted
- Milestone changed from 4.6.2.1 to 4.6.3
Moving this to 4.6.3