Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 1153411

Summary:	copy-in and copy-out copy symbolic link file problems, it only copy the link property not the real file
Product:	Red Hat Enterprise Linux 7	Reporter:	Lingfei Kong <lkong>
Component:	libguestfs	Assignee:	Richard W.M. Jones <rjones>
Status:	CLOSED NOTABUG	QA Contact:	Virtualization Bugs <virt-bugs>
Severity:	low	Docs Contact:
Priority:	medium
Version:	7.1	CC:	leiwang, mbooth, ptoscano, rjones, wshi, yuliu
Target Milestone:	rc
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:
Clones:	1153412 (view as bug list)		Environment:
Last Closed:	2014-10-21 07:00:46 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	1153412

Description Lingfei Kong 2014-10-16 02:44:22 UTC

Description of problem:
when copy-in/copy-out a symbolic link, the two APIs only copy the link property not the real file, some times it may have no problem but some times it will have a unexpected result.

When we copy ordinary symbolic links what we want is to copy the real file, in other words the TARGET files. 
When we copy directories, in most cases we want to keep the symbolic link in a directory. One reason is we want to keep the structure in the directory the other reason is the directory may contain links refer to a large file and we don't want to copy it or other reasons. 

The best way is to add an option to copy-in and copy-out to let the users to select if they want to follow the symbolic links like rsync. If copy-in and copy-out will not add such option, then at least it should add some text in help messages to describe this problem.  The same problem exist in virt-copy-in and virt-copy-out. 


Version-Release number of selected component (if applicable):
libguestfs-1.27.62-1.1.el7


How reproducible:
100%


Steps to Reproduce:
copy-in:
1. #echo "in host" > /etc/hosts.deny
2. #ln -s /etc/hosts.deny /etc/deny_link
3. #guestfish -i -a rhel.img
><fs> copy-in /etc/deny_link /etc/
><fs> ll /etc/deny_link
lrwxrwxrwx 1 root root 15 Oct 14 14:12 /sysroot/etc/deny_link -> /etc/hosts.deny

><fs> cat /etc/hosts.deny
#
# hosts.deny    This file contains access rules which are used to
#               deny connections to network services that either use
#               the tcp_wrappers library or that have been
#               started through a tcp_wrappers-enabled xinetd.
#
#               The rules in this file can also be set up in
#               /etc/hosts.allow with a 'deny' option instead.
#
#               See 'man 5 hosts_options' and 'man 5 hosts_access'
#               for information on rule syntax.
#               See 'man tcpd' for information on tcp_wrappers
#

copy-out:
4. #guestfish -i -a rhel.img
><fs> vi /etc/hosts.deny
><fs> cat /etc/hosts.deny
in guest

><fs> ln-s /etc/hosts.deny /etc/host_deny_link
><fs> copy-out  /etc/ .
><fs> quit
5. #ll etc/host_deny_link
lrwxrwxrwx. 1 root root 15 Oct 14 22:15 etc/host_deny_link -> /etc/hosts.deny
6. #cat etc/host_deny_link
in host


Actual results:
copy-in and copy-out only copy the link property not copy the real file.


Expected results:
At step 3, ><fs> cat /etc/hosts.deny should output "in host"
At step 6, #cat etc/host_deny_link should output "in guest"
copy-in and copy-out should copy the real file.


Additional info:

Comment 1 Lingfei Kong 2014-10-16 03:18:56 UTC

><fs> trace 1
><fs> copy-in soft_hosts /boot/
libguestfs: trace: is_dir "/boot/"
libguestfs: trace: is_dir = 1
libguestfs: trace: tar_in "/dev/fd/10" "/boot/"
libguestfs: trace: tar_in = 0
><fs> ll /boot/soft_hosts
libguestfs: trace: ll "/boot/soft_hosts"
libguestfs: trace: ll = "lrwxrwxrwx 1 root root 5 Oct 16 03:11 /sysroot/boot/soft_hosts -> hosts\n"
lrwxrwxrwx 1 root root 5 Oct 16 03:11 /sysroot/boot/soft_hosts -> hosts

><fs> help copy-in
NAME
    copy-in - copy local files or directories into an image

DESCRIPTION
     copy-in local [local ...] /remotedir

    "copy-in" copies local files or directories recursively into the disk
    image, placing them in the directory called "/remotedir" (which must
    exist). This guestfish meta-command turns into a sequence of "tar-in"
    and other commands as necessary.
    ......

It use tar_in to copy the symbolic links, i found the following line in 'help copy-in':
This guestfish meta-command turns into a sequence of "tar-in" and other commands as necessary.
When it copy ordinary files maybe upload is best for it.

Comment 2 Richard W.M. Jones 2014-10-20 09:44:19 UTC

Copying just the symbolic link (not the pointed at content)
is the correct behaviour.

Comment 3 Lingfei Kong 2014-10-21 04:17:36 UTC

(In reply to Richard W.M. Jones from comment #2)
> Copying just the symbolic link (not the pointed at content)
> is the correct behaviour.

If so, this bug can be closed as NOTABUG, thanks.

Comment 4 Richard W.M. Jones 2014-10-21 07:00:46 UTC

Closing per comment 3.

Comment 5 Lingfei Kong 2014-10-23 08:54:42 UTC

(In reply to Richard W.M. Jones from comment #2)
> Copying just the symbolic link (not the pointed at content)
> is the correct behaviour.

Hi Rich
copy-in and copy-out's behavior is different with user's expect when they deal with symbolic links and there is no text to explain it. Do you think it is necessary to add some text to 'help copy-in' and 'help copy-out' to explain that the two API  just copy the symbolic link (not the pointed at content)? 

In 'help copy-in' i can see that copy-in turns into a sequence of "tar-in" and other commands as necessary. That is to say 'other commands' make it different from tar-in, when copy-in and copy-out will use 'other commands'? This can hlep to improve our test case for copy-in/copy-out. :-) 

Thanks and Best Regards

Comment 6 Richard W.M. Jones 2014-10-24 13:38:37 UTC

So no.  The rules are quite complex.  For example, downloading a
file will dereference the symbolic link, but uploading one won't.

I don't want to paint us into a corner by documenting the current
behaviour, since it might change in future.

Comment 7 Lingfei Kong 2014-10-24 13:43:55 UTC

(In reply to Richard W.M. Jones from comment #6)
> So no.  The rules are quite complex.  For example, downloading a
> file will dereference the symbolic link, but uploading one won't.
> 
> I don't want to paint us into a corner by documenting the current
> behaviour, since it might change in future.

Thanks very much!