This is a relict of early days of btrbk, and I have already hesitated
for too long to change the default from legacy "short" to sane "long"
format.
Tests show that the scheduling behaves in a sane/expected way if this
change is applied unattended. I suppose everybody who has
preserve_hour_of_day set is already using timestamp_format=long.
For the paranoid. For convenience, filename checking was removed in
[1], and quoting was (hopefully) implemented correctly in [2].
Allowing special characters as well as UTF8 leave behind a bad
feeling, as there are many special cases that needs to be taken care
of (e.g. newlines in file names, right-to-left encoding, etc.). In
order to mitigate attacks expoiting these error classes, leave an
option to power users which do only allow "sane" characters in their
filename hierarchy.
[1] 6a29b08f00 btrbk: remove filename restrictions
[2] acc7f9fc83 btrbk: quote unsafe characters in shell commands
New defaults gives the btrbk_direct_leaf snapshots higher preference
than the global ones resolved by parent-uuid (which are best-guess).
This way the parent has a higher chance of being a backup created by
btrbk, which results in "btrfs receive" to start work on a snapshot of
this (and preferably not on the "best-guess" ones).
- Create tree from /proc/self/mountinfo, and use it to find mount
points.
- Populate realpath cache from mount points, possibly reducing calls
to `realpath`.
- Replace btrfs_mountpoint with vinfo_mountpoint(fs_type => 'btrfs)
- Tidy action "ls".
- Move code
Use Text::CharWidth::mbswidth() if installed, fallback to
length(Encode::decode_utf8()), fallback to length().
- Text::CharWidth handles wide chars (e.g. asian, taking up two
columns on the terminal) correctly.
- length(Encode::decode_utf8()) handles single-width chars only, and
should be installed on most systems (perl >= v5.7.3).
- langth() counts bytes, as we do not convert anything to UTF-8 in
btrbk (NOT using `perl -CIOEioA` or binmode(STDOUT, ":utf8"))
As filenames can contain meta characters like '$', we can't just put
ssh commands in double quotes. E.g. the following would trigger
variable expansion on local shell:
ssh example.com "ls -l 'evil$x'"
Instead, we quote the ssh using single quotes (adding the need to
escape single quotes), while also quoting unsafe filenames using
single quotes. The above becomes:
ssh example.com 'ls -l '\''evil$x'\'''
Or more complex, for a file named "file with'single quotes'":
ssh example.com 'ls -l '\''file with'\''\'\'''\''single quotes'\''\'\'''\'''\'''
On the remote shell, this will expand to:
ls -l 'file with'\''single quotes'\'''