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

[Trevor DeVore]

Brian,

I can definitely test it out. I wouldn’t worry about symbolic links outside
the folder right now. I don’t believe it affects .frameworks.

-- 
Trevor DeVore

On Sat, Jul 21, 2018 at 10:24 AM Brian Milby via use-livecode <
use-livecode at lists.runrev.com> wrote:

> 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
> >
> _______________________________________________
> 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