Help with Bug #19550: Add support for symlinks to standalone builder

[Brian Milby]

Doing a little digging on this.

I'm pretty sure this impacts iOS in the same was as MacOS.

private command __revSBCopyFolder
User and group is copied if MacOS, but not Linux

private command __revSBCopyFile
Probably good that links are handled as files, because they technically are.

Prior to line 351 (probably 348), some code will be needed to determine if
we are currently dealing with a symbolic link.  On Linux, aliasReference
seems to work properly where on MacOS it only works for an actual alias
(returns empty for a symbolic link).  On MacOS, I'm seeing the type is
actually "rhapslnk" for symbolic links and "MACSalis" for an alias (if
others can confirm, I can use my code below).  Not sure about Windows.  So
something like this:

put (the platform is "macos" and (tFileType is "rhapslnk" or tFileType is
"MACSalis") \
    or (the platform is "linux" and aliasReference(pSourceFile) is not
pSourceFile) into tFileIsLink
    -- this does count on pSourceFile being an absolute link

I think that the problem is that LC is attempting to copy links like it
would a binary file which is what is causing the issue.  Lines 351-396 need
to be wrapped in another if statement that properly handles symbolic links.

if tFileIsLink then
   -- handle link
else
   -- existing code from 351-396
end if

The easy way would be to just copy the symbolic link directly without
validation.  For relative symbolic links within the copied folder
structure, this should be fine.  If the symbolic links point outside of the
copied structure (i.e. they are absolute to somewhere else in the file
system), then there could be an issue with the distributed app.  The
problem is that at the point of the copy, you don't have the full path of
the destination application (just the file itself), so we can't check and
be sure that the link points inside the app (unless pSettings is an array
that has that info).  We could check to be sure it is on the same volume
fairly easily.  I think it would be good to just flag it as a warning
instead of an error that halts the build, but would need to dig a bit to
see if/how that is possible.

@Mike
I don't think the links should be traversed at all, but maintained in the
destination app.

@Trevor
If I put together an updated file, could you test to see if my solution
works for you?  I just need to make sure I'm copying the link correctly and
also figure out what to do on Windows.

Thanks,
Brian


On Fri, Jul 20, 2018 at 10:41 AM, Mike Kerner via use-livecode <
use-livecode at lists.runrev.com> wrote:

> A couple of thoughts:
> 1) There might be cases where symlinks should not be traversed, so there
> probably should be an option to traverse or not
> 2) There are probably going to be cases where the symlinks are recursive.
> I think there should definitely be an option to resolve those.
>
> On Fri, Jul 20, 2018 at 10:58 AM Trevor DeVore via use-livecode <
> use-livecode at lists.runrev.com> wrote:
>
> > Hi everyone,
> >
> > I’m writing this email to see if there is someone who can pitch in and
> > implement a fix for bug 19550 [1]. The issue is that the the copy folder
> > command that the LC standalone builder uses does not support symlinks.
> > While this hasn’t been a significant problem in the past, it has now
> become
> > one because LiveCode Builder (LCB) code can link to .frameworks on macOS
> > using the Foreign Function Interface (FFI) feature in LiveCode 9.
> >
> > As an example, I’ve been working on an LCB wrapper around Sparkle [2] and
> > on another around MASShortcut [3]. In both cases the .framework needs to
> be
> > distributed with the LCB library. The Standalone Builder does not create
> a
> > proper copy of the .framework and the code will fail in a standalone.
> >
> > Here is a link to the source code on GitHub that needs to be updated:
> >
> >
> > https://github.com/livecode/livecode/blob/e6955bb9dc517ba4c5c2da422deb5e
> 16627ebf1f/ide-support/revsblibrary.livecodescript#L215
> >
> > If someone is able to step in and modify the existing code to support
> > symlinks then others would be able to start distributing extensions that
> > use .frameworks on macOS. I haven’t verified whether or not this affects
> > iOS but it may.
> >
> > [1] https://quality.livecode.com/show_bug.cgi?id=19550
> > [2] https://github.com/trevordevore/lc-sparkle
> > [3] https://github.com/trevordevore/lc-masshortcut
> >
> > --
> > Trevor DeVore
> > ScreenSteps
> > www.screensteps.com
> > _______________________________________________
> > use-livecode mailing list
> > use-livecode at lists.runrev.com
> > Please visit this url to subscribe, unsubscribe and manage your
> > subscription preferences:
> > http://lists.runrev.com/mailman/listinfo/use-livecode
>
>
>
> --
> On the first day, God created the heavens and the Earth
> On the second day, God created the oceans.
> On the third day, God put the animals on hold for a few hours,
>    and did a little diving.
> And God said, "This is good."
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>