+++ This bug was initially created as a clone of Bug #1811539 +++

Description of problem:
The virt-diff command doesn't work on windows 2019 image.


Version-Release number of selected component (if applicable):
libguestfs-1.38.4-15.module+el8.2.0+5297+222a20af.x86_64
libguestfs-winsupport-8.2-1.module+el8.2.0+5590+82cd80df.x86_64
qemu-kvm-2.12.0-98.module+el8.2.0+5698+10a84757.x86_64


How reproducible:
100%


Steps:

1. Prepare a Windows Server 2019 image on rhel8.2 host

2.
# virt-inspector -a Win2019-64-hvm.raw
<?xml version="1.0"?>
<operatingsystems>
  <operatingsystem>
    <root>/dev/sda2</root>
    <name>windows</name>
    <arch>x86_64</arch>
    <distro>windows</distro>
    <product_name>Windows Server 2019 Standard</product_name>
    <product_variant>Server</product_variant>
    <major_version>10</major_version>
    <minor_version>0</minor_version>
    <windows_systemroot>/Windows</windows_systemroot>
    <windows_current_control_set>ControlSet001</windows_current_control_set>
    <hostname>WIN-HFJMM8K3DD1</hostname>
    <mountpoints>
      <mountpoint dev="/dev/sda2">/</mountpoint>
    </mountpoints>
    <filesystems>
      <filesystem dev="/dev/sda2">
        <type>ntfs</type>
        <uuid>E6B6D14EB6D1203B</uuid>
      </filesystem>
    </filesystems>
    <drive_mappings>
      <drive_mapping name="C">/dev/sda2</drive_mapping>
    </drive_mappings>
    <applications>
      <application>
        <name>winscp3_is1</name>
        <display_name>WinSCP 5.14 beta</display_name>
        <version>5.14 beta</version>
        <install_path>C:\Program Files (x86)\WinSCP\</install_path>
        <publisher>Martin Prikryl</publisher>
        <url>https://winscp.net/</url>
      </application>
    </applications>
  </operatingsystem>
</operatingsystems>

3.
# cp Win2019-64-hvm.raw Win2019-64-hvm-copy.raw

4.
# virt-diff -a Win2019-64-hvm.raw -A Win2019-64-hvm-copy.raw
libguestfs: error: internal_lxattrlist: getxattr: Argument list too long
libguestfs: error: internal_lxattrlist: getxattr: Argument list too long



Actual results:
There are some errors.

Expected results:
No error output.


Additional info:

--- Additional comment from Richard W.M. Jones on 2020-03-09 11:30:28 CET ---

Apparently this error means:

       E2BIG  The  size of the attribute value is larger than the maximum size
              allowed; the attribute cannot be retrieved.  This can happen  on
              filesystems  that  support  very  large attribute values such as
              NFSv4, for example.

I think I'm going to have to get access to this disk image.  Is it possible
you could make the file available somewhere for me to download?

--- Additional comment from YongkuiGuo on 2020-03-09 13:10:38 CET ---

(In reply to Richard W.M. Jones from comment #1)
> Apparently this error means:
> 
>        E2BIG  The  size of the attribute value is larger than the maximum
> size
>               allowed; the attribute cannot be retrieved.  This can happen 
> on
>               filesystems  that  support  very  large attribute values such
> as
>               NFSv4, for example.
> 
> I think I'm going to have to get access to this disk image.  Is it possible
> you could make the file available somewhere for me to download?

I have sent the image location to you by email.

--- Additional comment from Richard W.M. Jones on 2020-03-09 17:30:26 CET ---

Thanks for the image.  Weirdly this fails for me in libguestfs 1.41.8,
but works in libguestfs 1.42.0.  I believe the only difference this might
be caused by is ntfs-3g system compression (bug 1796073).  Still investigating.

--- Additional comment from Richard W.M. Jones on 2020-03-09 17:32:35 CET ---

By the way, an easy way to see the problem is:

$ virt-rescue --ro -a Win2019-64-hvm.img
><rescue> mount /dev/sda2 /sysroot/
><rescue> ls -l '/sysroot/Program Files/Common Files/microsoft shared/MSInfo'

In libguestfs 1.41 or RHEL AV:

ls: cannot access '/sysroot/Program Files/Common Files/microsoft shared/MSInfo/msinfo32.exe': Input/output error
total 0
drwxrwxrwx 1 root root 0 Sep 15  2018 en-US
-????????? ? ?    ?    ?            ? msinfo32.exe
><rescue> ls -l '/sysroot/Program Files/Common Files/microsoft shared/MSInfo/msinfo32.exe' 
lrwxrwxrwx 2 root root 25 Feb  4 11:14 '/sysroot/Program Files/Common Files/microsoft shared/MSInfo/msinfo32.exe' -> 'unsupported reparse point'

In libguestfs 1.42.0:

><rescue> ls -l '/sysroot/Program Files/Common Files/microsoft shared/MSInfo'
total 227
drwxrwxrwx 1 root root      0 Sep 15  2018 en-US
-r-xr-xr-x 2 root root 367104 Feb  4 11:14 msinfo32.exe

--- Additional comment from Richard W.M. Jones on 2020-03-09 17:54:24 CET ---

Sorry IGNORE comment 4, it is wrong.  This does have to do with NTFS
compression, but not in the way I described in the comment above.

In fact the reproducer is below, and this happens on all versions of
libguestfs and ntfs-3g, even with the latest Fedora:

$ virt-rescue --ro -a Win2019-64-hvm.img
><rescue> mount /dev/sda2 /sysroot/
><rescue> getfattr -d '/sysroot/Program Files/Common Files/microsoft shared/MSInfo/msinfo32.exe' 
/sysroot/Program Files/Common Files/microsoft shared/MSInfo/msinfo32.exe: user.WofCompressedData: Argument list too long

Notice the extended attribute which fails is ‘user.WofCompressedData’.
From a comment in the source code to ntfs-3g-system-compression we can
see this is related to NTFS compression:

 * Rather than building it directly into NTFS, Microsoft implemented this new
 * compression mode using the Windows Overlay Filesystem (WOF) filter driver
 * that was added in Windows 8.1.  A system-compressed file contains the
 * following NTFS attributes:
 *
 * - A reparse point attribute in the format WOF_FILE_PROVIDER_REPARSE_POINT_V1,
 *   documented below
 * - A sparse unnamed data attribute, containing all zero bytes, with data size
 *   equal to the uncompressed file size
 * - A data attribute named "WofCompressedData" containing the compressed data
 *   of the file.

Obviously this attribute can be rather large, since it contains the
compressed data of the whole file.

I guess the easiest thing for libguestfs to do is simply ignore this attribute
if we see it.  The various libguestfs xattr APIs probably shouldn't completely fail
when an over-long attribute is seen anyway.

--- Additional comment from YongkuiGuo on 2020-03-10 09:54:04 CET ---

Thanks rjones, it's very clear.

--- Additional comment from Richard W.M. Jones on 2020-03-12 15:45:12 CET ---

Patch posted:
https://www.redhat.com/archives/libguestfs/2020-March/msg00099.html

--- Additional comment from Richard W.M. Jones on 2020-03-16 14:59:57 CET ---

v2 patch posted:
https://www.redhat.com/archives/libguestfs/2020-March/msg00128.html

--- Additional comment from Richard W.M. Jones on 2020-03-30 12:58:48 CEST ---

Upstream in:
https://github.com/libguestfs/libguestfs/commit/5c175fe73264bbf1d3ef79bb066dfb6aff902ad1
https://github.com/libguestfs/libguestfs/commit/af8ed266a282bb20882a9ffb611bd64243d19218
https://github.com/libguestfs/libguestfs/commit/c2c11382bbeb4500f3388a31ffd08cfc18b0de40