Ross,

From: Burton, Ross [mailto:ross.bur...@intel.com]
Sent: Wednesday, September 27, 2017 9:06 AM
To: Bryan Evenson <beven...@melinkcorp.com>
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] Errors building with Windows Subsystem for Linux (aka Bash 
on Ubuntu on Windows)

On 27 September 2017 at 13:57, Bryan Evenson 
<beven...@melinkcorp.com<mailto:beven...@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.

I think I found the problem.  I started looking at more file properties for the 
files that worked and the ones that didn’t, and I noticed that all the ones 
that failed show a link count of 1024.  The Windows filesystem has a link limit 
of 1023 links per file (at least as reported here: 
https://msdn.microsoft.com/en-us/library/windows/desktop/aa363860(v=vs.85).aspx),
 so I think the hard link is failing due to the Windows link limit.  If that is 
the case, then I don’t think it’ll be a quick fix to get a working solution 
under WSL.

Bryan
-- 
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Reply via email to