Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

[Bug 229208] `install -l rs` (relative symlink to source) into

1 view
Skip to first unread message

bugzilla...@freebsd.org

unread,
Jun 21, 2018, 10:23:18 AM6/21/18
to
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229208

Bug ID: 229208
Summary: `install -l rs` (relative symlink to source) into
directory creates invalid symlink
Product: Base System
Version: 11.1-RELEASE
Hardware: Any
OS: Any
Status: New
Severity: Affects Some People
Priority: ---
Component: bin
Assignee: bu...@FreeBSD.org
Reporter: andreas....@googlemail.com

Created attachment 194459
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=194459&action=edit
Unit test which depicts expected behavior but currently fails

Good on 10.3-RELEASE:

$ rm -rf /tmp/dest && mkdir /tmp/dest && touch /tmp/myfile && cd /tmp &&
install -l rs ./myfile /tmp/dest && ls -la /tmp/dest
total 146
drwxr-xr-x 2 rmg-builder wheel 3 Jun 21 14:12 .
drwxrwxrwt 16 root wheel 613 Jun 21 14:12 ..
lrwxr-xr-x 1 rmg-builder wheel 9 Jun 21 14:12 myfile -> ../myfile

Bad on 11.1-RELEASE and 11.2-rc3:

$ rm -rf /tmp/dest && mkdir /tmp/dest && touch /tmp/myfile && cd /tmp &&
install -l rs ./myfile /tmp/dest && ls -la /tmp/dest
total 8
drwxr-xr-x 2 vagrant wheel 512 Jun 21 13:01 .
drwxrwxrwt 7 root wheel 512 Jun 21 13:01 ..
lrwxr-xr-x 1 vagrant wheel 8 Jun 21 13:01 myfile -> ./myfile

It seems that unit tests were only added to the source code after 10.4, and I
don't even know how the tool should behave. My expectation would be the
previous behavior, obviously, also because `install src
dest_which_is_a_directory` would normally be expected to create
`dest_which_is_a_directory/basename_of_src`.

Please find attached a new unit test to check for the old behavior. Did not dig
too deep into the code (usr.bin/xinstall/xinstall.c) yet to find a solution. My
feeling is that the function `makelink(...)` isn't even called in the buggy
case but probably should. Sharing it so more people can take a look.

I stumbled upon this because the ports tree macro `RLN` (see bsd.commands.mk)
is doing exactly this, and broke our software build on 11.x for internal ports.

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
freebs...@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs...@freebsd.org"

bugzilla...@freebsd.org

unread,
Jun 21, 2018, 3:14:15 PM6/21/18
to
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229208

--- Comment #1 from Andreas Sommer <andreas....@googlemail.com> ---
I was mistaken – the `makelink` function *is* called but has the following,
very explicit logic to handle this case

if (*from_name != '/') {
/* this is already a relative link */
do_symlink(from_name, to_name, target_sb);
/* XXX: from_name may point outside of destdir. */
metadata_log(to_name, "link", NULL, from_name, NULL, 0);
return;
}

So it seems on purpose, but is still a breaking change from FreeBSD 10.x.
Please advise. The manpage has no hint about the exact behavior. It reads

The file(s) are copied (or linked if the -l option is specified) to the
target file or directory. If the destination is a directory, then the file
is copied into directory with its original filename.

which leaves it open for humans to interpret what happens.

bugzilla...@freebsd.org

unread,
Jun 22, 2018, 4:56:44 AM6/22/18
to
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229208

--- Comment #2 from Andreas Sommer <andreas....@googlemail.com> ---
For users who are hit by this issue: the workaround is to specify the source as
absolute path (see code snippet which distinguishes here).
0 new messages