OVMF: cross-filesystem copy broken? ("The source and destination are the same")

OVMF: cross-filesystem copy broken? ("The source and destination are the same")

[Bruce Cran]

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


-- 
Bruce

Re: OVMF: cross-filesystem copy broken? ("The source and destination are the same")

[Laszlo Ersek]

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

Re: OVMF: cross-filesystem copy broken? ("The source and destination are the same")

[Bruce Cran]

On 11/17/2016 2:35 AM, Laszlo Ersek wrote:

> 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?

Unfortunately the patch doesn't fix the problem I'm seeing.

-- 
Bruce

Re: OVMF: cross-filesystem copy broken? ("The source and destination are the same")

[Laszlo Ersek]

On 11/17/16 16:24, Bruce Cran wrote:
> On 11/17/2016 2:35 AM, Laszlo Ersek wrote:
> 
>> 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?
> 
> Unfortunately the patch doesn't fix the problem I'm seeing.
> 

Thanks for trying it.

Unfortunately, I can't find the time to dig into this now. And, I think
it's likely related to ShellPkg anyway. Can you please help by filing a
BZ for ShellPkg, and/or bisecting the issue (assuming you remember the
same command working at some point)?

... I observe that the least recent commit that affected "Cp.c" with any
potential to break it like this could be

commit fbd2dfadfe6fb16ab7b49fca3764e05e65d97b8a
Author: Qiu Shumin <shumin.qiu@intel.com>
Date:   Fri Oct 23 02:03:20 2015 +0000

    ShellPkg: Follow spec to remove the last '\' char in return name of
GetCurDir().

but that commit is more than a year old now... So I'm not sure. Could be
one of the underlying helper functions. Time to pull out GDB and single
step the code? :)

Thanks!
Laszlo

Re: OVMF: cross-filesystem copy broken? ("The source and destination are the same")

[Palmer, Thomas]

Laszlo, et al~

I recently encountered a "cp" failure on OVMF whereby cp always thought my source and destination file paths were equivalent.  Turns out that StrniCmp function was broken b/c the InternalCharToUpper declaration in UefiShellLevel2CommandsLib.c was missing the EFIAPI token.  Once I added EFIAPI back, my cp command worked.

I'm on vacation so I can't write up a formal patch right now.   Give it a try and if it works please write up a patch, else I'll get back to it when I get back.


Regards,

Thomas Palmer

"I have only made this letter longer because I have not had the time to make it shorter" - Blaise Pascal


-----Original Message-----
From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Laszlo Ersek
Sent: Thursday, November 17, 2016 10:07 AM
To: Bruce Cran <bruce@cran.org.uk>; edk2-devel (edk2-devel@lists.01.org) <edk2-devel@ml01.01.org>
Cc: Wu, Hao A <hao.a.wu@intel.com>; Ni, Ruiyu <ruiyu.ni@intel.com>; Gao, Liming <liming.gao@intel.com>
Subject: Re: [edk2] OVMF: cross-filesystem copy broken? ("The source and destination are the same")

On 11/17/16 16:24, Bruce Cran wrote:
> On 11/17/2016 2:35 AM, Laszlo Ersek wrote:
> 
>> 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?
> 
> Unfortunately the patch doesn't fix the problem I'm seeing.
> 

Thanks for trying it.

Unfortunately, I can't find the time to dig into this now. And, I think it's likely related to ShellPkg anyway. Can you please help by filing a BZ for ShellPkg, and/or bisecting the issue (assuming you remember the same command working at some point)?

... I observe that the least recent commit that affected "Cp.c" with any potential to break it like this could be

commit fbd2dfadfe6fb16ab7b49fca3764e05e65d97b8a
Author: Qiu Shumin <shumin.qiu@intel.com>
Date:   Fri Oct 23 02:03:20 2015 +0000

    ShellPkg: Follow spec to remove the last '\' char in return name of GetCurDir().

but that commit is more than a year old now... So I'm not sure. Could be one of the underlying helper functions. Time to pull out GDB and single step the code? :)

Thanks!
Laszlo
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: OVMF: cross-filesystem copy broken? ("The source and destination are the same")

[Gao, Liming]

This should be root cause. 

edk2\MdePkg\Library\BaseLib\String.c line 554 to implement InternalCharToUpper() with EFIAPI.
CHAR16
EFIAPI
InternalCharToUpper (
  IN      CHAR16                    Char
  )

edk2\ShellPkg\Library\UefiShellLevel2CommandsLib\UefiShellLevel2CommandsLib.c line 271 declares it without EFIAPI. So, they don't match each other. 
CHAR16
InternalCharToUpper (
  IN CONST CHAR16                    Char
  );

Thanks
Liming
> -----Original Message-----
> From: Palmer, Thomas [mailto:thomas.palmer@hpe.com]
> Sent: Thursday, December 15, 2016 6:09 AM
> To: Laszlo Ersek <lersek@redhat.com>; Bruce Cran <bruce@cran.org.uk>;
> edk2-devel (edk2-devel@lists.01.org) <edk2-devel@ml01.01.org>
> Cc: Wu, Hao A <hao.a.wu@intel.com>; Ni, Ruiyu <ruiyu.ni@intel.com>; Gao,
> Liming <liming.gao@intel.com>
> Subject: RE: [edk2] OVMF: cross-filesystem copy broken? ("The source and
> destination are the same")
> 
> Laszlo, et al~
> 
> I recently encountered a "cp" failure on OVMF whereby cp always thought
> my source and destination file paths were equivalent.  Turns out that
> StrniCmp function was broken b/c the InternalCharToUpper declaration in
> UefiShellLevel2CommandsLib.c was missing the EFIAPI token.  Once I added
> EFIAPI back, my cp command worked.
> 
> I'm on vacation so I can't write up a formal patch right now.   Give it a try and
> if it works please write up a patch, else I'll get back to it when I get back.
> 
> 
> Regards,
> 
> Thomas Palmer
> 
> "I have only made this letter longer because I have not had the time to make
> it shorter" - Blaise Pascal
> 
> 
> -----Original Message-----
> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of
> Laszlo Ersek
> Sent: Thursday, November 17, 2016 10:07 AM
> To: Bruce Cran <bruce@cran.org.uk>; edk2-devel (edk2-devel@lists.01.org)
> <edk2-devel@ml01.01.org>
> Cc: Wu, Hao A <hao.a.wu@intel.com>; Ni, Ruiyu <ruiyu.ni@intel.com>; Gao,
> Liming <liming.gao@intel.com>
> Subject: Re: [edk2] OVMF: cross-filesystem copy broken? ("The source and
> destination are the same")
> 
> On 11/17/16 16:24, Bruce Cran wrote:
> > On 11/17/2016 2:35 AM, Laszlo Ersek wrote:
> >
> >> 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?
> >
> > Unfortunately the patch doesn't fix the problem I'm seeing.
> >
> 
> Thanks for trying it.
> 
> Unfortunately, I can't find the time to dig into this now. And, I think it's likely
> related to ShellPkg anyway. Can you please help by filing a BZ for ShellPkg,
> and/or bisecting the issue (assuming you remember the same command
> working at some point)?
> 
> ... I observe that the least recent commit that affected "Cp.c" with any
> potential to break it like this could be
> 
> commit fbd2dfadfe6fb16ab7b49fca3764e05e65d97b8a
> Author: Qiu Shumin <shumin.qiu@intel.com>
> Date:   Fri Oct 23 02:03:20 2015 +0000
> 
>     ShellPkg: Follow spec to remove the last '\' char in return name of
> GetCurDir().
> 
> but that commit is more than a year old now... So I'm not sure. Could be one
> of the underlying helper functions. Time to pull out GDB and single step the
> code? :)
> 
> Thanks!
> Laszlo
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel