This is the mail archive of the
mailing list for the Cygwin project.
Re: mkshortcut (cygutils-1.4.14) free error
- From: Anthony Heading <anthony at ajrh dot net>
- To: cygwin at cygwin dot com
- Date: Tue, 27 Oct 2015 20:30:32 -0400
- 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>
On Tue, Oct 27, 2015, at 01:29 AM, Mark Geisert wrote:
> I really appreciate the leads and code you've provided. Could we
> please discuss only on the Cygwin mailing list? That's the convention
> we have, barring extraordinary circumstances :) . It allows for
> public review.
I believe I did send everything to the mailing list. I may have copied
you directly also. Apologies if that was inconvenient.
> At that point I could reproduce your first mkshortcut issue. Your
> patch seems to fix that issue. So far, so good.
> 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.
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. 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.
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.
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple