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 1216296 - rm-rf does not follow symlinks
Summary: rm-rf does not follow symlinks
Keywords:
Status: CLOSED DUPLICATE of bug 1293271
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: libguestfs
Version: 6.7
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: rc
: ---
Assignee: Pino Toscano
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks: 1301844
TreeView+ depends on / blocked
 
Reported: 2015-04-29 04:28 UTC by Hu Zhang
Modified: 2016-02-02 03:39 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-02-01 07:28:05 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
log for virt-sysprep --delete (175.80 KB, text/plain)
2016-01-04 06:47 UTC, Xianghua Chen 		no flags Details
View All

Description Hu Zhang 2015-04-29 04:28:14 UTC 
Description of problem:
virt-sysprep with '--delete' option fails to delete the symbolic link to a directory. It can delete the symbolic link to a file. This works well in rhel7.1.


Version-Release number of selected component (if applicable):
libguestfs-1.20.11-14.el6.x86_64
libguestfs-tools-c-1.20.11-14.el6.x86_64

How reproducible:
Always

Steps to Reproduce:
1. Get a rhel image.

2. Start the guest and create a directory and a soft link point to it
...
><fs> mkdir /home/testdir
><fs> ln-s /home/testdir /home/testdir_link

3. delete the testdir_link
# virt-sysprep --delete /home/testdir_link -a $img

4. Chech in guest
# guestfish -a $img -i glob-expand '/home/testdir_link'

Actual results:
Step 4, it returns:
# guestfish -a $img -i glob-expand '/home/testdir_link'
/home/testdir_link/                                                                                    

Expected results:
The symbolic link to the /home/testdir should be deleted successfully.

Additional info:
Comment 2 Pino Toscano 2015-04-29 14:12:54 UTC 
virt-sysprep in the ends uses the rm-rf API, which just runs "rm -rf" from the appliance (outside the /sysroot chroot). The problem seems to be there, as it does not follow symlinks at all, neither absolute (like the provided example) nor relative.

This can be easily reproduced with:

$ guestfish -N fs <<EOF
mount /dev/sda1 /
mkdir /dir-abs
mkdir /dir-rel
touch /file-abs
touch /file-rel
ln-s /dir-abs /link-abs
ln-s dir-rel /link-rel
ln-s /file-abs /link-file-abs
ln-s file-rel /link-file-rel
ll /
rm-rf /link-abs
rm-rf /link-rel
rm-rf /link-file-abs
rm-rf /link-file-rel
ll /
EOF

If the bug is fixed, then second ll output will show only lost+found; if not, it will show also the two dir-abs and dir-rel directories and the two file-abs and file-rel files.

This fails for me everywhere (RHEL 6, RHEL 7, upstream too).

(In reply to Hu Zhang from comment #0)
> virt-sysprep with '--delete' option fails to delete the symbolic link to a
> directory. It can delete the symbolic link to a file. This works well in
> rhel7.1.

I tried and it fails the same way for me also in RHEL 7 and upstream. Can you please explain a bit more what test did you do?
Comment 3 Richard W.M. Jones 2015-04-29 14:37:34 UTC 
I'm not really convinced this is a bug.  Ordinary 'rm' on the host
doesn't follow symlinks either.
Comment 5 Xianghua Chen 2016-01-04 06:47:10 UTC 
Created attachment 1111339 [details]
log for virt-sysprep --delete

log for virt-sysprep --delete
Comment 6 Xianghua Chen 2016-01-04 06:48:05 UTC 
(In reply to Richard W.M. Jones from comment #3)
> I'm not really convinced this is a bug.  Ordinary 'rm' on the host
> doesn't follow symlinks either.

I tried in guestfish and found that you can only use "rm-rf /home/testdir_link" to delete the symlink (it's same as the host):
$ guestfish -a RHEL-Server-6.7-32-hvm.raw -i
><fs> rm-rf /home/testdir_link/
><fs> ls /home/
testdir
testdir_link
><fs> rm-rf /home/testdir_link
><fs> ls /home/
testdir

So,I think the problem is, It should call "rm_rf /home/testdir_link" instead of "rm_rf /home/testdir_link/" when using:" virt-sysprep --delete /home/testdir_link -a $img"

Please refer to the detailed log attached.
Comment 7 Xianghua Chen 2016-01-04 06:48:54 UTC 
*** Bug 1293271 has been marked as a duplicate of this bug. ***
Comment 8 Xianghua Chen 2016-02-01 07:28:05 UTC 

*** This bug has been marked as a duplicate of bug 1293271 ***
Comment 9 Pino Toscano 2016-02-01 12:35:30 UTC 
(In reply to Xianghua Chen from comment #8)
> 
> *** This bug has been marked as a duplicate of bug 1293271 ***

I'm not sure this is the case: this bug is just part of what bug 1293271 describes (and part of that can affect also upstream versions), so fixing bug 1293271 would not fix this one.

Also, per comment #3 this might not be a bug at all.
Comment 10 Xianghua Chen 2016-02-02 03:39:25 UTC 
(In reply to Pino Toscano from comment #9)
> (In reply to Xianghua Chen from comment #8)
> > 
> > *** This bug has been marked as a duplicate of bug 1293271 ***
> 
> I'm not sure this is the case: this bug is just part of what bug 1293271
> describes (and part of that can affect also upstream versions), so fixing
> bug 1293271 would not fix this one.
> 
> Also, per comment #3 this might not be a bug at all.

I closed it as duplicate because the steps and the problem of the two bug were exactly the same, but this one may be has an confused subject, because the rm actually acts the same as on the host as described in comment #3 . 
So, the problem is not about rm , please refer to comment #6.
Note You need to log in before you can comment on or make changes to this bug.