- Errors building with Windows Subsystem for Linux (aka Bash on Ubuntu on Windows)
Re: Errors building with Windows Subsystem for Linux (aka Bash on Ubuntu on Windows)
toggle quoted messageShow quoted text
From: Burton, Ross [mailto:ross.burton@...]
Sent: Wednesday, September 27, 2017 9:06 AM
To: Bryan Evenson <bevenson@...>
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 <bevenson@...> 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.
Join email@example.com to automatically receive all group messages.