Red Hat Bugzilla – Bug 892834
guestmount: rename() incorrectly follows symbolic links
Last modified: 2013-11-20 23:42:39 EST
Description of problem: My project ostree implements atomic upgrades by swapping symbolic links. However, rename() incorrectly follows the symbolic link, instead of overwriting the target. Version-Release number of selected component (if applicable): libguestfs-1.16.34-2.el6.x86_64 fuse-2.8.3-4.el6.x86_64 kernel-2.6.32-350.el6.x86_64 How reproducible: Always. Expected results (ext4): $ mkdir adir $ mkdir bdir $ ln -s adir current $ ln -s bdir new $ mv -T -f new current $ ls -al total 16 drwxrwxr-x. 4 walters walters 4096 Jan 7 18:44 . drwxrwxr-x. 4 walters walters 4096 Jan 7 18:42 .. drwxrwxr-x. 2 walters walters 4096 Jan 7 18:42 adir drwxrwxr-x. 2 walters walters 4096 Jan 7 18:42 bdir lrwxrwxrwx. 1 walters walters 4 Jan 7 18:44 current -> bdir $ Actual results (guestfs): $ ls -al total 16 drwxr-xr-x. 2 root root 4096 Jan 7 17:45 . drwxr-xr-x. 12 root root 4096 Jan 7 17:45 .. drwxrwxr-x. 2 root root 4096 Jan 7 18:47 adir drwxrwxr-x. 2 root root 4096 Jan 7 18:46 bdir lrwxrwxrwx. 1 root root 4 Jan 7 18:46 current -> adir $ ls -al adir total 8 drwxrwxr-x. 2 root root 4096 Jan 7 18:47 . drwxr-xr-x. 4 root root 4096 Jan 7 18:47 .. lrwxrwxrwx. 1 root root 4 Jan 7 18:46 new -> bdir (where "new" is a broken symbolic link). Note to testers: the -T argument to "mv" is important, it will ensure we just use the kernel rename() call instead of following the target.
This request was not resolved in time for the current release. Red Hat invites you to ask your support representative to propose this request, if still desired, for consideration in the next release of Red Hat Enterprise Linux.
Requires the following commits: https://bugzilla.redhat.com/show_bug.cgi?id=895910#c3
Thanks! I'll try to get some time to do some testing on the latest Fedora builds (and/or try backporting these myself to RHEL 6.4)
This is fixed by the rebase (bug 958183).
Verified with libguestfs-1.20.9-6.el6 [root@]# guestmount -a test1.img -m /dev/sda1 /mnt [root@]# cd /mnt [root@dhcp-9-42 mnt]# ls lost+found [root@dhcp-9-42 mnt]# mkdir adir [root@dhcp-9-42 mnt]# mkdir bdir [root@dhcp-9-42 mnt]# ln -s adir current [root@dhcp-9-42 mnt]# ln -s bdir new [root@dhcp-9-42 mnt]# mv -T -f new current [root@dhcp-9-42 mnt]# ls -al total 19 drwxr-xr-x. 5 root root 1024 Jul 30 22:32 . dr-xr-xr-x. 28 root root 4096 Jul 29 18:08 .. drwxr-xr-x. 2 root root 1024 Jul 30 22:31 adir drwxr-xr-x. 2 root root 1024 Jul 30 22:31 bdir lrwxrwxrwx. 1 root root 4 Jul 30 22:31 current -> bdir drwx------. 2 root root 12288 Jul 30 22:30 lost+found Can get the current link to bdir, so change the status to verfied
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHSA-2013-1536.html