Copy symlinks to prevent bogus conversion to hard links

[okdana]

Fixes #1017 (?)

I have to admit, i know extremely little about Ruby and even less about fpm's internals. I tested this change on macOS 10.12.6 + Ruby 2.4.2 and on Ubuntu 16.04.3 + Ruby 2.3.1 (see #1017 for test cases), and it seems to produce the correct result on both, but that's the extent of what i tried. I don't have a Ruby development environment set up and am not sure how/if to run or update the unit tests. Someone else who knows better might want to double-check.

[glennpratt]

In my case, copies are just as bad as hardlinks. I'm building Ruby code into a package when bins are symlinked. Having them as copies mean relative file references fail.

[okdana]

I don't think the change works the way you think it does. It doesn't copy the targets

[Skarlso]

@okdana What @glennpratt was saying that the copies are also bad. We realise that this copies the source to the target destination which is just as bad as hardlinks.

[okdana]

? It copies the links themselves into the archive. If the source directory contains bar -> foo, you get an archive with bar -> foo:

heartswap:/tmp % mkdir test && echo hello > test/foo && ln -s foo test/bar
heartswap:/tmp % ls -Al test
total 4
lrwxr-xr-x  1 dana  wheel  3 15 Jul 09:05 bar -> foo
-rw-r--r--  1 dana  wheel  6 15 Jul 09:05 foo
heartswap:/tmp % fpm -s dir -t deb -n test -C test . &> /dev/null
heartswap:/tmp % dpkg -c test_1.0_darwin-amd64.deb
drwxr-xr-x 0/0               0 2019-07-15 09:05 ./
drwxr-xr-x 0/0               0 2019-07-15 09:05 ./usr/
drwxr-xr-x 0/0               0 2019-07-15 09:05 ./usr/share/
drwxr-xr-x 0/0               0 2019-07-15 09:05 ./usr/share/doc/
drwxr-xr-x 0/0               0 2019-07-15 09:05 ./usr/share/doc/test/
-rw-r--r-- 0/0             142 2019-07-15 09:05 ./usr/share/doc/test/changelog.gz
-rw-r--r-- 0/0               5 2019-07-15 09:05 ./foo
lrwxr-xr-x 0/0               0 2019-07-15 09:05 ./bar -> foo

Have you tested it and found that it doesn't behave this way in some cases? Or else in what way would it break relative file references?

[Skarlso]

Hm, I see what you mean, I might have also misunderstood this. It appears to be working when I tried this.

[Skarlso]

Yep, thanks this actually worked.

[salim-runsafe]

We are running into the issue seemingly fixed by this PR. I see that the CI failed for it, but the results are long gone. Is there a way to rerun that so we can try and address the failure?

[jordansissel]

CI hasn’t worked correctly in some time, so I’m not sure if the results are worth worrying about. Sorry for the confusion.

Looks like there are reports that this patch does fix the issue. I’ll take a look when I can.

On Fri, Aug 13, 2021 at 12:32 PM salim-runsafe @.***> wrote:

We are running into the issue seemingly fixed by this PR. I see that the CI failed for it, but the results are long gone. Is there a way to rerun that so we can try and address the failure?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/jordansissel/fpm/pull/1445#issuecomment-898677466, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABAF2QHC6ZUNNNQ7B3YCZLT4VXNNANCNFSM4EIBBNYA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email .

[p--b]

We are also encountering the issue fixed by this PR with debs built by fpm. Is there any movement on potentially getting this merged?