… rookie … On the whole I am really impressed …
If you haven't been there already: <https://freebsdfoundation.org/> in particular, yesterday's Technology Roadmap and (more generally) the Journal.
… rookie … On the whole I am really impressed …
Normally on FreeBSD, system-wide defaults are stored in /etc and /usr/local/etc. This is straight from the Handbook. I would suggest that you spend some quality time reading it, it contains a surprising amount of useful info to get you started on a LOT of stuff.
If you haven't been there already: <https://freebsdfoundation.org/> in particular, yesterday's Technology Roadmap and (more generally) the Journal.
Correct, but a clean install gives you these files in the root dir, hard linked to the ones in /root. They're referenced by /etc/freebsd-update.conf and /usr/sbin/mergemaster. From the latter:Normally on FreeBSD, system-wide defaults are stored in /etc and /usr/local/etc.
echo " *** Historically BSD derived systems have had a"
echo " hard link from /.cshrc and /.profile to"
echo " their namesakes in /root. Please indicate"
echo " your preference below for bringing your"
echo " installed files up to date."
pw useradd
may need them.hard linked
You might also find these Desktop Tutorials useful too.Excellent thanks. I have been reading parts of it, but as you say it contains such a surprising amount of useful info that sometimes it is very easy to get lost in it!
Fantastic. I have been finding as much interesting documentation as I can, I have read a few of the journal articles already, but did not see this page. Rather remarkable how much info is on here!
You can useGiven the inode (number) of a file, how does a person discover the names/paths?
find / -inum 47
to do so.root@throwaway:/ # bfs / -inum 28
/.cshrc
/dev/klog
/root/.cshrc
root@throwaway:/ # bfs / -inum 30
/.profile
/dev/io
/root/.profile
root@throwaway:/ # file /dev/klog
/dev/klog: character special (0/28)
root@throwaway:/ # file /dev/io
/dev/io: character special (0/30)
root@throwaway:/ # exit
Given the inode (number) of a file, how does a person discover the names/paths?
find
will not always give satisfactory results, performance wise.$ ls -il /bin/tcsh /bin/csh
48635176 -r-xr-xr-x 2 root wheel 424304 Feb 8 2021 /bin/csh
48635176 -r-xr-xr-x 2 root wheel 424304 Feb 8 2021 /bin/tcsh
% touch file1 ; ls -il
total 0
34759410 -rw-r--r-- 1 sox sox 0 Sep 19 20:45 file1
% ln file1 file2 ; ls -il
total 0
34759410 -rw-r--r-- 2 sox sox 0 Sep 19 20:45 file1
34759410 -rw-r--r-- 2 sox sox 0 Sep 19 20:45 file2
% rm file1 ; ls -il
total 0
34759410 -rw-r--r-- 1 sox sox 0 Sep 19 20:45 file2
… exactly 2 references active to that specific inode …
… a clean install gives you these files in the root dir, hard linked to the ones in /root. …
$ stat -x /.cshrc
$ stat -x /dev/klog
# find / -inum 7
/dev/console
/root/.cshrc
/.cshrc
bfs
(in # bfs / -inum 28
) had something to do with btrfs, clearly not correct. I think that you've defined that as an alias for some incarnation of find
.… I would be staggered if anything relied on those links today. Having said that, I leave them in place, …
clean installation
root@throwaway:/ # pkg info
bfs-2.2.1 Breadth-first version of the UNIX find command
pkg-1.16.3 Package manager
… suspect that traversing (parts of) a large filesystem withfind
will not always give satisfactory results, performance wise. …
bfs
were (with minimal file systems) fractionally faster. From <https://github.com/tavianator/bfs#user-content-breadth-vs-depth>:… The advantage of breadth-first over depth-first search is that it usually finds the file(s) you're looking for faster. …
The separation of OS and other software (pkg or ports) is great.Hi everyone. I have used Linux since
freebsd-update
is quite slow but you learn to live with it, kinda has its charm.Thanks guys some interesting discussion on those files. I noticed there are about four files in my /tmp directory on startup that have a . in front like .ICE-unix, do these serve any purpose outside of an X server?
5.2. Socket directory ownership and permissions
The socket directories created in /tmp are now required to be owned by root and have their sticky-bit set. If the premissions are not set correctly, the component using this directory will print an error message and fail to start. Common socket directories that are known to be affected include:
/tmp/.font-unix
/tmp/.ICE-unix
/tmp/.X11-unix
These directories are used by the font server, xfs, applications using the Inter-Client Exchange protocol (ICE) and the X server, respectively.
There are several solutions to the problem of when to create these directories. They could be created at install time by the system's installer if the /tmp dir is persistent. They could be created at boot time by the system's boot scripts (e.g., the init.d scripts). Or, they could be created by PAM modules at service startup or user login time.
The solution chosen is platform dependent, and the system administrator should be able to handle creating those directories on any systems that do not have the correct ownership or permissions.
/usr/share/skel/Where is the default? (Does it check .cshrc, then /root/.cshrc, and then where?)
-m This option instructs pw to attempt to create the user's
home directory. While primarily useful when adding a new
account with useradd, this may also be of use when moving
an existing user's home directory elsewhere on the file
system. The new home directory is populated with the
contents of the skeleton directory, which typically
contains a set of shell configuration files that the user
may personalize to taste. Files in this directory are
usually named dot.⟨config⟩ where the dot prefix will be
stripped. When -m is used on an account with usermod,
existing configuration files in the user's home directory
are not overwritten from the skeleton files.
Startup and shutdown
A login shell begins by executing commands from the system files
/etc/csh.cshrc and /etc/csh.login. It then executes commands from
files in the user's home directory: first ~/.tcshrc (+) or, if
~/.tcshrc is not found, ~/.cshrc, then the contents of ~/.history (or
the value of the histfile shell variable) are loaded into memory, then
~/.login, and finally ~/.cshdirs (or the value of the dirsfile shell
variable) (+). The shell may read /etc/csh.login before instead of
after /etc/csh.cshrc, and ~/.login before instead of after ~/.tcshrc or
~/.cshrc and ~/.history, if so compiled; see the version shell
variable. (+)
Non-login shells read only /etc/csh.cshrc and ~/.tcshrc or ~/.cshrc on
startup.
Invocation
If no arguments are present and if the standard input of the shell is
connected to a terminal (or if the -i option is set), the shell is
considered an interactive shell. An interactive shell generally prompts
before each command and handles programming and command errors
differently (as described below). When first starting, the shell
inspects argument 0, and if it begins with a dash (‘-’), the shell is
also considered a login shell. This is normally done automatically by
the system when the user first logs in. A login shell first reads
commands from the files /etc/profile and then .profile in a user's home
directory, if they exist. If the environment variable ENV is set on
entry to a shell, or is set in the .profile of a login shell, the shell
then subjects its value to parameter expansion and arithmetic expansion
and reads commands from the named file. Therefore, a user should place
commands that are to be executed only at login time in the .profile file,
and commands that are executed for every shell inside the ENV file. The
user can set the ENV variable to some file by placing the following line
in the file .profile in the home directory, substituting for .shrc the
filename desired:
ENV=$HOME/.shrc; export ENV
The first non-option argument specified on the command line will be
treated as the name of a file from which to read commands (a shell
script), and the remaining arguments are set as the positional parameters
of the shell ($1, $2, etc.). Otherwise, the shell reads commands from
its standard input.
Unlike older versions of sh the ENV script is only sourced on invocation
of interactive shells. This closes a well-known, and sometimes easily
exploitable security hole related to poorly thought out ENV scripts.
Thanks yes I have clear_tmp_enable set but did not notice them disappear, perhaps because they are hidden? Would these files be created by an xorg install if they were removed manually before doing so?Code:5.2. Socket directory ownership and permissions The socket directories created in /tmp are now required to be owned by root and have their sticky-bit set. If the premissions are not set correctly, the component using this directory will print an error message and fail to start. Common socket directories that are known to be affected include: /tmp/.font-unix /tmp/.ICE-unix /tmp/.X11-unix These directories are used by the font server, xfs, applications using the Inter-Client Exchange protocol (ICE) and the X server, respectively. There are several solutions to the problem of when to create these directories. They could be created at install time by the system's installer if the /tmp dir is persistent. They could be created at boot time by the system's boot scripts (e.g., the init.d scripts). Or, they could be created by PAM modules at service startup or user login time. The solution chosen is platform dependent, and the system administrator should be able to handle creating those directories on any systems that do not have the correct ownership or permissions.
^^this info may be outdated, as it it from 2005 , but yea, they are X-relevant files, you don't need to worry about them.
Do you have clear_tmp_enable="YES" in /etc/rc.conf?
No, they would not. AndWould these files be created by an xorg install if they were removed manually before doing so?
clear_tmp_enable
actually creates them if they're missing (which would happen if you used tmpfs(5) for /tmp for example and rebooted). But it does clear /tmp of everything else. Stuff in /tmp is not guaranteed to survive a reboot (see hier(7)). # X related directories to create in /tmp.
local x11_socket_dirs="${tmp}/.X11-unix ${tmp}/.XIM-unix \
${tmp}/.ICE-unix ${tmp}/.font-unix"
daily_clean_tmps_enable
you can set in /etc/periodic.conf (it's disabled by default). And that too ignores those directories. By default, unless you modified daily_clean_tmps_ignore
. daily_clean_tmps_ignore=".X*-lock .X11-unix .ICE-unix .font-unix .XIM-unix"
daily_clean_tmps_ignore="$daily_clean_tmps_ignore quota.user quota.group .snap"
daily_clean_tmps_ignore="$daily_clean_tmps_ignore .sujournal"
No, they would not. Andclear_tmp_enable
actually creates them if they're missing (which would happen if you used tmpfs(5) for /tmp for example and rebooted). But it does clear /tmp of everything else. Stuff in /tmp is not guaranteed to survive a reboot (see hier(7)).
See /etc/rc.d/cleartmpCode:# X related directories to create in /tmp. local x11_socket_dirs="${tmp}/.X11-unix ${tmp}/.XIM-unix \ ${tmp}/.ICE-unix ${tmp}/.font-unix"
UFS file system snapshots are stored in that directory:./.snap/ I cleared as it looks like it is for recovery (is that autogenerated when needed if I delete it?)
trev@shadow [/.snap] $ ll
total 58912
-r--r----- 1 root operator 3.8G 24 Sep 14:58 snapshot_20210906040300
-r--r----- 1 root operator 3.8G 24 Sep 14:58 snapshot_20210907040300
-r--r----- 1 root operator 3.8G 24 Sep 14:58 snapshot_20210908040300
-r--r----- 1 root operator 3.8G 24 Sep 14:58 snapshot_20210909040300
-r--r----- 1 root operator 3.8G 24 Sep 14:58 snapshot_20210910040300
-r--r----- 1 root operator 3.8G 24 Sep 14:58 snapshot_20210911040300
-r--r----- 1 root operator 3.8G 24 Sep 14:58 snapshot_20210912040300
-r--r----- 1 root operator 3.8G 24 Sep 14:58 snapshot_20210913040300
-r--r----- 1 root operator 3.8G 24 Sep 14:58 snapshot_20210914040300
-r--r----- 1 root operator 3.8G 24 Sep 14:58 snapshot_20210915040300
-r--r----- 1 root operator 3.8G 24 Sep 14:58 snapshot_20210916040300
-r--r----- 1 root operator 3.8G 24 Sep 14:58 snapshot_20210917040300
-r--r----- 1 root operator 3.8G 24 Sep 14:58 snapshot_20210918040300
-r--r----- 1 root operator 3.8G 24 Sep 14:58 snapshot_20210919040300
-r--r----- 1 root operator 3.8G 24 Sep 16:35 snapshot_20210920040300
-r--r----- 1 root operator 3.8G 24 Sep 16:35 snapshot_20210921040300
-r--r----- 1 root operator 3.8G 24 Sep 16:35 snapshot_20210922040300
-r--r----- 1 root operator 3.8G 24 Sep 16:35 snapshot_20210923040300
-r--r----- 1 root operator 3.8G 24 Sep 16:35 snapshot_20210924040300