321094 |
17-Jul-2017 |
ngie |
MFC r319856,r320172,r320173:
r319856:
Add a testcase for `ln -sF`
The testcase fails today, so mark it with atf_expect_fail: in particular, the target (B) isn't being unlinked and the documentation doesn't suggest special handling for directories. Thus, there's either a doc or an implementation bug in ln(1) that needs to be resolved.
MFC with: r319714, r319854, r319855 PR: 219943
r320172:
ln(1): fix -F behavior
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
r320173:
Don't expect :sF_flag to fail anymore
While here, also add a check to verify that the link target is updated in the testcase
MFC with: r320172 PR: 219943 |
319714 |
08-Jun-2017 |
asomers |
Add tests for ln(1)
* Verify that when creating a hard link to a symbolic link, '-L' option creates a hard link to the target of the symbolic link * Verify that when creating a hard link to a symbolic link, '-P' option creates a hard link to the symbolic link itself * Verify that if the target file already exists, '-f' option unlinks it so that link may occur * Verify that if the target file or directory is a symbolic link, '-shf' option prevents following the link * Verify that if the target file or directory is a symbolic link, '-snf' option prevents following the link * Verify that '-s' option creates a symbolic link * Verify that '-w' option produces a warning if the source of a symbolic link does not currently exist
Submitted by: shivansh Reviewed by: asomers, ngie MFC after: 1 month Sponsored by: Google, Inc (GSoC 2017) Differential Revision: https://reviews.freebsd.org/D11084
|