From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 4484181F06 for ; Thu, 17 Nov 2016 01:35:37 -0800 (PST) Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id EF09EA2021; Thu, 17 Nov 2016 09:35:41 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-6.phx2.redhat.com [10.3.116.6]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id uAH9Zdcn006474; Thu, 17 Nov 2016 04:35:40 -0500 To: Bruce Cran , "edk2-devel (edk2-devel@lists.01.org)" References: <47cd17d8-f022-6ca5-2f52-06a8250f8d14@cran.org.uk> Cc: "Wu, Hao A" , "Ni, Ruiyu" , "Gao, Liming" From: Laszlo Ersek Message-ID: Date: Thu, 17 Nov 2016 10:35:39 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <47cd17d8-f022-6ca5-2f52-06a8250f8d14@cran.org.uk> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Thu, 17 Nov 2016 09:35:42 +0000 (UTC) Subject: Re: OVMF: cross-filesystem copy broken? ("The source and destination are the same") X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2016 09:35:37 -0000 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit On 11/17/16 04:11, Bruce Cran wrote: > I don't know if this is a known issue, but it appears that > cross-filesystem copies no longer work. I'm running OVMF X64 built from > git commit a0426207c133bdf40c42561f26c20c4b3114d8f9. I've tried copying > between filesystems in various ways - with the current directory being > fs0, fs1, specifying the destination as the current directory, a empty > directory or a filename. It always results in the same error: > > FS0:\efi\ubuntu\> cp grubx64.efi fs1:\ > > cp: The source and destination are the same. > > > I built OVMF with: `./OvmfPkg/build.sh -a X64 -t GCC49 -b NOOPT -D > DEBUG_ON_SERIAL_PORT=TRUE` and am running OVMF with: > > > qemu-system-x86_64 -name uefi -M q35 -m size=16G -cpu host -enable-kvm \ > -drive > if=pflash,format=raw,file=workspace/edk2/Build/OvmfX64/NOOPT_GCC49/FV/OVMF.fd > -serial pty \ > -nodefaults -s -rtc base=utc -monitor stdio --usbdevice tablet \ > -vga qxl -sdl \ > -device vfio-pci,host=01:00.0,id=iodrive,rombar=0 \ > -drive file=uefi.img,if=ide,media=disk,id=disk,format=raw \ > -drive file=uefi_tmp.img,if=ide,media=disk,id=disk1,format=raw > > I wonder if you are running into this BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=239 There's a patch on the list for said BZ: [edk2] [PATCH v2] API PathRemoveLastItem not handle root paths properly so if the BZ is indeed what you're encountering, then the patch should fix it for you. Can you please test it and report back in that thread? The error message that you see corresponds to the STR_CP_SD_SAME token. It is emitted by the ValidateAndCopyFiles() function, in "ShellPkg/Library/UefiShellLevel2CommandsLib/Cp.c". However, the same function calls PathRemoveLastItem() in a loop first, so I suspect the patch is related to the symptom you see. Thanks Laszlo