Red Hat Bugzilla – Bug 1267032
guestfish copy-in command behaves oddly/unexpectedly with wildcards
Last modified: 2016-11-03 13:56:00 EDT
Description of problem: $ guestfish -N fs -m /dev/sda1 ><fs> copy-in /tmp/* / ><fs> ll / total 17 drwxr-xr-x 3 root root 1024 Sep 28 21:04 . drwxr-xr-x 19 root root 4096 Sep 28 21:03 .. drwx------ 2 root root 12288 Sep 28 21:03 lost+found Assuming you have some files in local directory /tmp then you would expect that copy-in /tmp/* / would either copy all the files in, or would give an error. Note that the correct behaviour is *not* to copy all the files in because guestfish doesn't expand wildcards at all, and certainly not local files. http://libguestfs.org/guestfish.1.html#wildcards-and-globbing But the lack of some kind of error message is strange. Version-Release number of selected component (if applicable): libguestfs-1.31.7-1.fc24.x86_64 Reported by a customer using libguestfs 1.28.1 from RHEL 7.1. How reproducible: 100% Steps to Reproduce: 1. As above.
Note that using the wildcard on the command line works, because bash expands it. This is all as expected: $ mkdir /tmp/d $ for f in `seq 1 10`; do touch /tmp/d/$f; done $ ls /tmp/d 1 10 2 3 4 5 6 7 8 9 $ guestfish -N fs -m /dev/sda1 copy-in /tmp/d/* / : ll / total 17 drwxr-xr-x 3 root root 1024 Sep 28 21:11 . drwxr-xr-x 19 root root 4096 Sep 28 21:11 .. -rw-rw-r-- 1 1000 1000 0 Sep 28 21:10 1 -rw-rw-r-- 1 1000 1000 0 Sep 28 21:10 10 -rw-rw-r-- 1 1000 1000 0 Sep 28 21:10 2 -rw-rw-r-- 1 1000 1000 0 Sep 28 21:10 3 -rw-rw-r-- 1 1000 1000 0 Sep 28 21:10 4 -rw-rw-r-- 1 1000 1000 0 Sep 28 21:10 5 -rw-rw-r-- 1 1000 1000 0 Sep 28 21:10 6 -rw-rw-r-- 1 1000 1000 0 Sep 28 21:10 7 -rw-rw-r-- 1 1000 1000 0 Sep 28 21:10 8 -rw-rw-r-- 1 1000 1000 0 Sep 28 21:10 9 drwx------ 2 root root 12288 Sep 28 21:11 lost+found
Even worse is: $ guestfish -N fs -m /dev/sda1 copy-in /tmp/nosuchfile / : ll / $ echo $? 1 It exits with an error code, which is good, but no error message.
Patch series posted: https://www.redhat.com/archives/libguestfs/2015-September/msg00086.html
Fixed upstream (in 1.31.8). We'll pick these patches up in the rebase.
Not reproduced with the packages: libguestfs-1.28.1-1.18.el7.x86_64 libguestfs-1.28.1-1.55.el7.x86_64 They both return one error message: # guestfish -N fs -m /dev/sda1 copy-in /tmp/nosuchfile / : ll / tar: nosuchfile: Cannot stat: No such file or directory tar: Exiting with failure status due to previous errors This error message is not the same as the fixed. But it still makes sense.
Verified with the packages: libguestfs-1.32.5-6.el7.x86_64 Verify steps: 1. On host: # mkdir -p /tmp/d/testdir # touch /tmp/d/testfile 2. # guestfish -N fs -m /dev/sda1 copy-in /tmp/d/* / : ll / total 18 drwxr-xr-x 4 root root 1024 Jun 28 04:26 . drwxr-xr-x 19 root root 4096 Jun 28 04:26 .. drwx------ 2 root root 12288 Jun 28 04:26 lost+found drwxr-xr-x 2 root root 1024 Jun 28 04:25 testdir -rw-r--r-- 1 root root 0 Jun 28 04:25 testfile Note: Using the wildcard on the command line works. 3. # guestfish -N fs -m /dev/sda1 copy-in /tmp/nosuchfile / : ll / libguestfs: error: source '/tmp/nosuchfile' does not exist (or cannot be read) # guestfish -N fs -m /dev/sda1 ><fs> copy-in /tmp/d/* / libguestfs: error: source '/tmp/d/*' does not exist (or cannot be read) It gives obvious error message as above. So verified.
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. https://rhn.redhat.com/errata/RHSA-2016-2576.html