On 27 September 2017 at 13:57, Bryan Evenson <bevenson@melinkcorp.com> wrote:


Feel free to compress and email it directly to me, but simply grepping for EINVAL (invalid argument error) might be enough.

 

I did a search on EINVAL and I got a bunch of entries of that look like this:

 

  linkat(AT_FDCWD, “<source_full_path>”, AT_FDCWD, “<dest_full_path>”, 0) = -1 EINVAL (Invalid argument)

 

I checked a few entries by doing a stat on the source and destination.  In each case, the source file exists at the specified path, was owned by the user account with which I’m doing the build, and had access rights of 0644.  Also in each case, the destination file did not exist but the destination directory did exist, the destination directory was owned by the user account with which I’m doing the build, and the destination directory had access rights of 0755.  From reading the man page for linkat, linkat should only return EINVAL if the flags argument is invalid, and 0 should be a valid value for flags.

 

I think there may be something missing from WSL’s implementation of linkat.  I am doing OPKG packages, so I’m guessing there is something different about the resulting function calls in the libc-package class as opposed to the package_ipk class.  I think I may enable the other package types to see if it is as successfully with RPMs and DEB packages.  I’m also going to see if there is an easier way to reproduce the problem to report the issue to Microsoft.


Good digging.  At least you can replicate it on demand, and have a strace showing it.  This bit of packaging happens before the rpm/opkg/deb specific code, so changing the packaging format won't help.

Ross