directories to SUBDIR.${MK_TESTS} idiom
This is being done to pave the way for future work (and homogenity) in
^/projects/make-check-sandbox .
No functional change intended.
MFC after: 1 weeks
While here, also add a check to verify that the link target
is updated in the testcase
MFC after: 1 month
MFC with: r320172
PR: 219943
Differential Revision: D11167
Submitted by: shivansh
Sponsored by: Google (GSoC 2017)
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'
MFC after: 1 month
PR: 219943
Differential Revision: D11167
Submitted by: shivansh
Sponsored by: Google (GSoC 2017)
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 after: 1 month
MFC with: r319714, r319854, r319855
PR: 219943
Reviewed by: ngie
Submitted by: shivansh
Differential Revision: D11159 (part of a larger diff)
Sponsored by: Google, Inc (GSoC 2017)
file(1) can be compiled out of the system via MK_FILE == no, and the
output isn't guaranteed to be stable. It's better to use stat(1)/readlink(1)
instead to query symlink/file paths.
MFC after: 1 month
MFC with: r319714, r319854
Reported by: ngie
Submitted by: shivansh
Differential Revision: D11159 (part of a larger diff)
Sponsored by: Google, Inc (GSoC 2017)
* 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
Renumber cluase 4 to 3, per what everybody else did when BSD granted
them permission to remove clause 3. My insistance on keeping the same
numbering for legal reasons is too pedantic, so give up on that point.
Submitted by: Jan Schaumann <jschauma@stevens.edu>
Pull Request: https://github.com/freebsd/freebsd/pull/96
Note: tcsh(1) has a MK_TCSH=no test, so this should be a separate
package, which requires pre-install/post-install scripts, to be
added later.
Sponsored by: The FreeBSD Foundation
Off by default, build behaves normally.
WITH_META_MODE we get auto objdir creation, the ability to
start build from anywhere in the tree.
Still need to add real targets under targets/ to build packages.
Differential Revision: D2796
Reviewed by: brooks imp
The core kernel part is patch file utimes.2008.4.diff from
pluknet@FreeBSD.org. I updated the code for API changes, added the manual
page and added compatibility code for old kernels. There is also audit and
Capsicum support.
A new UTIME_* constant might allow setting birthtimes in future.
Differential Revision: https://reviews.freebsd.org/D1426
Submitted by: pluknet (partially)
Reviewed by: delphij, pluknet, rwatson
Relnotes: yes
For these simple utilities, it doesn't harm to make all global variables
static. In fact, this allows the compiler to perform better forms of
optimisation and analysis.
in at least three ways, so do not say it is ignored:
* who may delete/rename a symlink in a sticky directory
* who may do lchflags(2)/lchown(2)/lchmod(2)
* whose inode quota is charged
MFC after: 1 week
In the 'ln source... directory' synopsis, the basename of each source
determines the name of the created link. Determine this using basename(3)
instead of strrchr(..., '/') which is incorrect if the pathname ends in a
slash.
The patch is somewhat changed to allow for basename(3) implementations that
change the passed pathname, and to fix the -w option's checking also.
The code to compare directory entries only applies to hard links, which
cannot be created to directories using ln.
Example:
ln -s /etc/defaults/ /tmp
This should create a symlink named defaults.
PR: 121568
Submitted by: Ighighi
MFC after: 1 week
Two pathnames refer to the same directory entry iff the directories match
and the final components' names match.
Example: (assuming file1 is an existing file)
ln -f file1 file1
This now fails while leaving file1 intact. It used to delete file1 and then
complain it cannot be linked because it is gone.
With -i, this error is detected before the question is asked.
MFC after: 2 weeks
This implements the POSIX.1-2008 -L and -P flags.
The default remains to create hard links to the target of symlinks.
Approved by: re (kib), ed (mentor)
Cast string precision to `int'. amd64 systems warn about the
field precision being `long int' if we don't, and pathnames are
normally short enough to fit in an `int'.
Noticed by: pav
ln(1) checks to see if the source of a symlink, i.e. the file it
should point to actually exists. The default is the old ln
behavior, that does not check, to avoid surprising people who may
be using ln(1) in scripts or other non-interactive places.
PR: bin/7265
Submitted by: Joel Ray Holveck, detlev!joelh at mail.camalott.com
MFC after: 2 weeks
