This is the mail archive of the
mailing list for the Cygwin project.
Re: mkshortcut (cygutils-1.4.14) free error
- From: Mark Geisert <mark at maxrnd dot com>
- To: cygwin at cygwin dot com
- Date: Wed, 28 Oct 2015 04:49:27 +0000 (UTC)
- Subject: Re: mkshortcut (cygutils-1.4.14) free error
- Authentication-results: sourceware.org; auth=none
- References: <1445135414 dot 3384650 dot 413058409 dot 46BC94AD at webmail dot messagingengine dot com> <1445823930 dot 241438 dot 419951441 dot 109BA262 at webmail dot messagingengine dot com> <562E30AF dot 5020502 at cornell dot edu> <loom dot 20151026T205200-829 at post dot gmane dot org> <1445904708 dot 1171081 dot 420968713 dot 3D94007E at webmail dot messagingengine dot com> <loom dot 20151027T061000-194 at post dot gmane dot org> <1445992232 dot 1521329 dot 422055817 dot 4924D989 at webmail dot messagingengine dot com>
Anthony Heading writes:
> > The second issue with the non-absolute path is more problematic.
> > Without your second patch, I do see the issue but only on the 2nd or
> > later invocation. In other words, if the xyzzy.lnk file does not
> > initially exist, the command 'src/mkshortcut/.libs/mkshortcut xyzzy'
> > works and does create the link file. Another invocation then shows the
> > error. Is it simply mis-reporting that there's an existing link file?
> Yes. The hint in the error message is unhelpful I think, since a missing
> directory is only one of a myriad of possible errors. As you note, an
> existing link prompts the same message.
Re the unhelpful hint, I was considering removing the guess it's making or
substituting something more generic. I'm not sure it would help. If
there were some way to get the underlying Windows error code we might be
able to map it to an errno but that seems like it might not be robust. If
we only have OLE/COM error codes like the "E_FAIL" for an existing link
file, it seems hopeless. I'll probably leave the error message text as-is
> On the build I made on Windows 10, however, I hit the problem on the
> very first invocation. I imagine you therefore are building on Windows 7
> or earlier, which seems to produce binaries that work OK.
Yes, I'm building on Windows 7, 64- and 32-bit as well as Windows XP. No
plans at present to upgrade but I might need to consider VMs to test later
> As I said, I
> suspect this is because IPersistFile::Save has changed semantics, e.g.
> per this link:
> I haven't verified this; I don't know how why or whether gcc is
> volunteering the executable to run in Windows 8 mode, or if there's a
> manifest in some dll library stub, or whether the COM ID of the
> IPersistFile interface is redirected by newer headers, or any similar
> variant of Windows black magic, but it seems to me like a good guess.
I'll happily defer to your understanding of Those Black Arts :).
> If you're going to stay building on Windows 7 then, I don't think this
> latter patch is needed, although it's hopefully harmless. But I guess
> without it the code will silently break when Windows 8 or newer comes
> into the picture.
I think we should take advantage of the detective work you've done and
patch as you've suggested. I'll add a comment to the effect that it's for
a specific Windows behavior change seen after Windows 7. I'll add a link
to that MSDN page if our coding/doc conventions allow for that.
Thanks again for your patient and detailed help on this!
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple