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

Brian Milby brian at milby7.com
Sat Jul 21 23:31:01 EDT 2018 

Finally working on the actual code in the IDE and discovered that there is
a failure in a different spot than I thought.  "there is a file" returns
false on symbolic links.  So my initial solution is going to need some more
work.

Also, file copy failures are not propagated up the call chain.  First issue
is that the __revSBCopyFile handler just "returns" tResult instead of using
"for error".  But it doesn't really matter since when you go up a couple
levels, it isn't passed further.

And lastly, there is a "move" that takes place somewhere else that is
causing an issue.  I've got the initial copy working, but when this next
step happens it messes up folder symbolic links (files links remain).  This
is on the Mac... I have not testing in Linux yet (not to mention figuring
out the Windows side).  Not sure why it copies to /Contents/MacOS and then
moves it to /Contents/Resources/_MacOS.  I'm just testing with a folder
that I put in the "copy files" section of the builder.

I should be able to sort it out, but will take a little longer than I
thought.

On Sat, Jul 21, 2018 at 10:59 AM, Trevor DeVore via use-livecode <
use-livecode at lists.runrev.com> wrote:

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

More information about the use-livecode mailing list