Fix behavior for '-F' option of ln(1)

[shivansh]

Summary

When '-F' option is used, the target directory needs to be unlinked.
Currently, the modified target ("target/source") is being unlinked, and
since it doesn't yet exist, the original target isn't removed.
This is fixed by skipping the block where target is modified to
"target/source" when '-F' option is set.
Hence, a symbolic link (with the same name as of the original target) to
the source_file is produced.

Update the test for ln(1) to reflect fix for option '-F'

PR: 219943

Test Plan

• Run make install from bin/ln/tests.
• Run kyua test from /usr/tests/bin/ln. All 12 test cases should succeed.

[asomers]

Would it not suffice to simply skip the block at line 250 when Fflag is set?

[shivansh]

Oh, right! We can simply modify the if clause to skip it -

if (!Fflag && (isdir ||
	    (lstat(target, &sb) == 0 && S_ISDIR(sb.st_mode)) ||
	    (!hflag && stat(target, &sb) == 0 && S_ISDIR(sb.st_mode)))) {

Will wait for others to comment before updating.

[shivansh]

Fix as per instructed by @asomers

Updated summary -
When '-F' option is used, the target directory needs to be unlinked.
Currently, the modified target ("target/source") is being unlinked, and
since it doesn't yet exist, the original target isn't removed.
This is fixed by skipping the block where target is modified to
"target/source" when '-F' option is set.
Hence, a symbolic link (with the same name as of the original target) to
the source_file is produced.

[asomers]

LGTM. I'll commit tomorrow AM if no other reviewers have comments.

[ngie]

bin/ln/ln.c

247–248 ↗

(On Diff #29520)

This comment should be updated for the change.

[shivansh]

Update comment

[ngie]

bin/ln/ln.c

249 ↗

(On Diff #29526)

This sounds wordy. Let me think about this a bit.

[ngie]

bin/ln/ln.c

248 ↗

(On Diff #29526)

• source's name. -> source's name, unless Fflag is set.

[shivansh]

Update comment

I am suspecting that some other commits are also going to be included in this update. I don't think doing an interactive rebase caused the problem, but I have tried updating my remote, hard resetting it to the original state at the time the diff was sent, but (I think) in vain.
If the changes aren't included, then it's fine. If they are, I'll figure something out.

[ngie]

In D11167#233594, @shivansh wrote:

Update comment

I am suspecting that some other commits are also going to be included in this update. I don't think doing an interactive rebase caused the problem, but I have tried updating my remote, hard resetting it to the original state at the time the diff was sent, but (I think) in vain.
If the changes aren't included, then it's fine. If they are, I'll figure something out.

No worries.. I can parse out the changes.

One that specify revisions/git hashes with arc diff --update.