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

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Clarence Martin via use-livecode
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/e6955bb9dc517ba4c5c2da422deb5e16627ebf1f/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
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

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

Clarence Martin via use-livecode
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 <
[hidden email]> 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/e6955bb9dc517ba4c5c2da422deb5e16627ebf1f/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
> [hidden email]
> 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
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

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

Clarence Martin via use-livecode
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 <
[hidden email]> 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 <
> [hidden email]> 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
> > [hidden email]
> > 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
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

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

Clarence Martin via use-livecode
Brian-

Here's the code I use in PowerTools to determine in a cross-platform way
whether a filespec is a file or a folder. The Windows code is pretty
stupid, just looking at the file extension, but I couldn't think of a
better way to figure it out. HTH.

/**
* ----------------------------------------
* IsFolder
*
* Determine whether the given filespec is a folder (true) or a file (false)
* @pFileSpec : path reference to a folder or file
* ----------------------------------------
*/
private function isFolder pFileSpec
    local tIsFolder
    local tFile, tFiles
    local tTarget
    local tData
    local tAlias
    local tDefaultFolder

    put false into tIsFolder
    if there is a folder pFileSpec then
       -- see if it's an LC8 extension
       put FilesOfFolder(pFileSpec) into tFiles
       filter tFiles with "*.lcm"
       if tFiles is empty then
          -- not an extension, it's a real folder
          put true into tIsFolder
       end if
    else
       -- must be a file reference
       put aliasreference(pFileSpec) into tAlias
       switch the platform
          case "Win32"
             -- aliasreference returns empty on OSX, filespec on linux
             if tAlias is not empty and tAlias is not pFileSpec then
                if IsFolder(tAlias) then
                   put true into tIsFolder
                else
                   put false into tIsFolder
                end if
             end if
             break
          case "MacOS"
             -- ignore Windows link files
             if char -4 to -1 of pFileSpec is ".lnk" then
                put false into tIsFolder
             end if
             break
          case "linux"
             -- ignore Windows link files
             if char -4 to -1 of pFileSpec is ".lnk" then
                put false into tIsFolder
             else
                put shell("ls -l" && quote & pFileSpec & quote) into tFile
                if char 1 of tFile is "l" then
                   set the itemdelimiter to ">"
                   put item -1 of tFile into tTarget
                   if the number of lines in tTarget > 1 then
                      put true into tIsFolder
                   end if
                end if
             end if
       end switch
    end if
    return tIsFolder
end isFolder

--
  Mark Wieder
  [hidden email]

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

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

Clarence Martin via use-livecode
In reply to this post by Clarence Martin via use-livecode
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 <
[hidden email]> 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 <
> [hidden email]> 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 <
> > [hidden email]> 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
> > > [hidden email]
> > > 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
> > [hidden email]
> > Please visit this url to subscribe, unsubscribe and manage your
> > subscription preferences:
> > http://lists.runrev.com/mailman/listinfo/use-livecode
> >
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

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

Clarence Martin via use-livecode
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 <
[hidden email]> 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 <
> [hidden email]> 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 <
> > [hidden email]> 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 <
> > > [hidden email]> 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
> > > > [hidden email]
> > > > 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
> > > [hidden email]
> > > Please visit this url to subscribe, unsubscribe and manage your
> > > subscription preferences:
> > > http://lists.runrev.com/mailman/listinfo/use-livecode
> > >
> > _______________________________________________
> > use-livecode mailing list
> > [hidden email]
> > Please visit this url to subscribe, unsubscribe and manage your
> > subscription preferences:
> > http://lists.runrev.com/mailman/listinfo/use-livecode
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

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

Clarence Martin via use-livecode
Found something very interesting and I think it may be a bug (at least an
anomaly)...

if you rename a symbolic link to a folder, the folder that is pointed to is
renamed vice the link

consider the following (-> denotes a symbolic link)
~/tmp/
~/tmp2 -> ./tmp/

rename "~/tmp2" "~/tmp3"

results in

~/tmp2 -> (broken link, still points to ./tmp/ which does not exist)
~/tmp3/

I checked on MacOS and Linux.
The call causing this problem is in "revRedirectMacOSResourcesRecurse"

This particular issue won't impact ".bundle", ".app", nor ".framework"
folders since they are not relocated.
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

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

Clarence Martin via use-livecode
PR 6611 created for this issue on develop-9.0
https://github.com/livecode/livecode/pull/6611

The submitted change will preserve symbolic links.  Relative links that go
outside of the included directory will probably break.  Absolute links may
not work on other machines.  All framework links should be self-contained
and work fine.

Ended up using "mv" on Mac/Linux to rename the files to preserve directory
symbolic links.

Something interesting that I discovered, if you use a symbolic link as the
folder to include, it already would resolve that link and copy the actual
linked directory into the app.  At the top of __revSBCopyFolder,
"revSBReadLink" turns the pSource into the actual path of the contents.  I
can't see a way to actually do this in the IDE though (if you choose a
symbolic link, then the referenced folder is what is added).

On Sat, Jul 21, 2018 at 11:25 PM, Brian Milby <[hidden email]> wrote:

> Found something very interesting and I think it may be a bug (at least an
> anomaly)...
>
> if you rename a symbolic link to a folder, the folder that is pointed to
> is renamed vice the link
>
> consider the following (-> denotes a symbolic link)
> ~/tmp/
> ~/tmp2 -> ./tmp/
>
> rename "~/tmp2" "~/tmp3"
>
> results in
>
> ~/tmp2 -> (broken link, still points to ./tmp/ which does not exist)
> ~/tmp3/
>
> I checked on MacOS and Linux.
> The call causing this problem is in "revRedirectMacOSResourcesRecurse"
>
> This particular issue won't impact ".bundle", ".app", nor ".framework"
> folders since they are not relocated.
>
>
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode