Man page - fsvs-groups(5)
Packages contains this manual
Manual
FSVS - Group definitions
NAMEOverview
Predefined group 1: āignoreā
Predefined group 2: ātakeā
Why should I ignore files?
Why should I assign groups?
Syntax of group files
Specification of groups and patterns
Shell-like patterns
Absolute shell patterns
PCRE-patterns
Ignoring all files on a device
Ignoring a single file, by inode
Modifiers
ātakeā: Take pattern
āignoreā: Ignore pattern
āinsensā or ānocaseā: Case insensitive
ādironlyā: Match only directories
āmodeā: Match entriesā mode
Examples
Author
NAME
Using grouping patterns -
Patterns are used to define groups for new entries; a group can be used to ignore the given entries, or to automatically set properties when the entry is taken on the entry list. Patterns are used to define groups for new entries; a group can be used to ignore the given entries, or to automatically set properties when the entry is taken on the entry list.
So the
auto-props are assigned when the entry gets put on the
internal list; that happens for the
add
,
prop-set
or
prop-del
, and of course
commit
commands.
To override the auto-props of some new entry just use the
property commands.
Overview
When FSVS walks through your working copy it tries to find new (ie. not yet versioned) entries. Every new entry gets tested against the defined grouping patterns (in the given order!); if a pattern matches, the corresponding group is assigned to the entry, and no further matching is done.
See also entry statii .
Predefined group 1: āignoreā
If an entry gets a group named āignoreā assigned, it will not be considered for versioning.
This is the only really special group name.
Predefined group 2: ātakeā
This group mostly specifies that no further matching is to be done, so that later ignore patterns are not tested.
Basically the ātakeā group is an ordinary group like all others; it is just predefined, and available with a short-hand notation .
Why should I ignore files?
Ignore patterns are used to ignore certain directory entries, where versioning makes no sense. If youāre versioning the complete installation of a machine, you wouldnāt care to store the contents of /proc (see man 5 proc ), or possibly because of security reasons you donāt want /etc/shadow , /etc/sshd/ssh_host_*key , and/or other password- or key-containing files.
Ignore patterns allow you to define which directory entries (files, subdirectories, devices, symlinks etc.) should be taken, respectively ignored.
Why should I assign groups?
The grouping patterns can be compared with the auto-props feature of subversion; it allows automatically defining properties for new entries, or ignoring them, depending on various criteria.
For example you might want to use encryption for the files in your usersā .ssh directory, to secure them against unauthorized access in the repository, and completely ignore the private key files:
Grouping patterns:
group:ignore,/home/*/.ssh/id*
group:encrypt,/home/*/.ssh/**
And the $FSVS_CONF/groups/encrypt file would have a definition for the fsvs:commit-pipe (see the special properties ).
Syntax of group files
A group definition file looks like this:
|
⢠|
Whitespace on the beginning and the end of the line is ignored. |
||
|
⢠|
Empty lines, and lines with the first non-whitespace character being ā#ā (comments) are ignored. |
||
|
⢠|
It can have either the keywords ignore or take ; if neither is specified, the group ignore has ignore as default (surprise, surprise!), and all others use take . |
||
|
⢠|
An arbitrary (small) number of lines with the syntax |
auto-prop property-name property-value can be given; property-name may not include whitespace, as thereās no parsing of any quote characters yet.
An example:
# This is a comment
# This is another
auto-props fsvs:commit-pipe gpg -er admin@my.net
# End of definition
Specification of groups and patterns
While an ignore
pattern just needs the pattern itself (in one of the formats
below), there are some modifiers that can be additionally
specified:
[group:{name},][dir-only,][insens|nocase,][take,][mode:A:C,]pattern
These are listed
in the section
Modifiers
below.
These kinds of ignore patterns are available:
Shell-like patterns
These must start with
./
, just like a base-directory-relative path. ? ,
*
as well as character classes [a-z] have their
usual meaning, and
**
is a wildcard for directory
levels.
You can use a backslash
\
outside of character
classes to match some common special characters literally,
eg.
\*
within a pattern will match a literal
asterisk character within a file or directory name. Within
character classes all characters except ] are treated
literally. If a literal ] should be included in a character
class, it can be placed as the first character or also be
escaped using a backslash.
Example for
/
as the base-directory
./[oa]pt
./sys
./proc/*
./home/**Ė
This would
ignore files and directories called
apt
or
opt
in the root directory (and files below, in the
case of a directory), the directory
/sys
and
everything below, the contents of
/proc
(but take
the directory itself, so that upon restore it gets created
as a mountpoint), and all entries matching
*Ė
in and below
/home
.
Note:
The patterns are anchored at the beginning and the end. So a pattern ./sys will match only a file or directory named sys . If you want to exclude a directoriesā files, but not the directory itself, use something like ./dir/* or ./dir/**
If youāre deep within your working copy and youād like to ignore some files with a WC-relative ignore pattern, you might like to use the rel-ignore command.
Absolute shell patterns
There is another way to specify
shell patterns - using absolute paths.
The syntax is similar to normal shell patterns; but instead
of the
./
prefix the full path, starting with
/
, is used.
/etc/**.dpkg-old
/etc/**.dpkg-bak
/**.bak
/**Ė
The advantage of using full paths is that a later
dump
and
load
in another working copy (eg.
when moving from versioning
/etc
to
/
)
does simply work; the patterns donāt have to be
modified.
Internally this simply tries to remove the working copy base
directory at the start of the patterns (on loading); then
they are processed as usual.
If a pattern does
not
match the wc base, and neither
has the wild-wildcard prefix
/**
, a
warning
is issued.
PCRE-patterns
PCRE stands for Perl Compatible
Regular Expressions; you can read about them with
man
pcre2
(if the manpages are installed), and/or
perldoc perlre
(if perldoc is installed).
If both fail for you, just google it.
These patterns have the form
PCRE:{pattern}
, with
PCRE
in uppercase.
An example:
PCRE:./home/.*Ė
This one
achieves exactly the same as
./home/**Ė
.
Another example:
PCRE:./home/[a-s]
This would match
/home/anthony
,
/home/guest
,
/home/somebody
and so on, but would not match
/home/theodore
.
One more:
PCRE:./.*(.(tmp|bak|sik|old|dpkg-120
Note that the pathnames start with ./ , just like above, and that the patterns are anchored at the beginning. To additionally anchor at the end you could use a $ at the end.
Ignoring all files on a device
Another form to discern what is
needed and what not is possible with
DEVICE:[<|<=|>|>=]major[:minor]
.
This takes advantage of the major and minor device numbers
of inodes (see
man 1 stat
and
man 2 stat
).
The rule is as follows:
|
⢠|
Directories have their parent matched against the given string |
|||
|
⢠|
All other entries have their own device matched. |
This is because mount-points
(ie. directories where other filesystems get attached) show
the device of the mounted device, but should be versioned
(as they are needed after restore); all entries (and all
binding mounts) below should not.
The possible options
<=
or
>=
define
a less-or-equal-than respective bigger-or-equal-than
relationship, to ignore a set of device classes.
Examples:
tDEVICE:3
./*
This patterns
would define that all filesystems on IDE-devices (with major
number 3) are
taken
, and all other files are
ignored.
DEVICE:0
This would ignore all filesystems with major number 0 - in
linux these are the
virtual
filesystems (
proc
,
sysfs
,
devpts
, etc.; see
/proc/filesystems
, the lines with
nodev
).
Mind NFS and smb-mounts, check if youāre using
md
,
lvm
and/or
device-mapper
!
Note: The values are parsed with
strtoul()
, so you
can use decimal, hexadecimal (by prepending
ā0xā
, like
ā0x102ā
) and octal
(
ā0ā
, like
ā0777ā
)
notation.
Ignoring a single file, by inode
At last, another form to ignore
entries is to specify them via the device they are on and
their inode:
INODE:major:minor:inode
This can be used
if a file can be hardlinked to many places, but only one
copy should be stored. Then one path can be marked as to
take
, and other instances can get ignored.
Note:
Thatās probably a bad example. There should be a better mechanism for handling hardlinks, but that needs some help from subversion.
Modifiers
All of these patterns can have
one or more of these modifiers
before
them, with
(currently) optional
ā,ā
as separators;
not all combinations make sense.
For patterns with the
m
(mode match) or
d
(dironly) modifiers the filename pattern gets optional; so
you donāt have to give an all-match wildcard pattern
(
./**
) for these cases.
ātakeā: Take pattern
This modifier is just a short-hand for assigning the group take .
āignoreā: Ignore pattern
This modifier is just a short-hand for assigning the group ignore .
āinsensā or ānocaseā: Case insensitive
With this modifier you can force the match to be case-insensitive; this can be useful if other machines use eg. samba to access files, and you cannot be sure about them leaving ā.BAKā or ā.bakā behind.
ādironlyā: Match only directories
This is useful if you have a directory tree in which only certain files should be taken; see below.
āmodeā: Match entriesā mode
This expects a specification of
two octal values in the form
m:
and_value
:
compare_value,
like
m:04:00
; the bits set in
and_value
get isolated from the entriesā
mode, and compared against
compare_value
.
As an example: the file has mode
0750
; a
specification of
|
⢠|
m:0700:0700 matches, |
|||
|
⢠|
m:0700:0500 doesnāt; and |
|||
|
⢠|
m:0007:0000 matches, but |
|||
|
⢠|
m:0007:0007 doesnāt. |
A real-world example:
m:0007:0000
would match all entries that have
no
right bits set for
āothersā
,
and could be used to exclude private files (like
/etc/shadow
). (Alternatively, the
others-read
bit could be used:
m:0004:0000
.
FSVS will reject invalid specifications, ie. when bits in
compare_value
are set that are cleared in
and_value:
these patterns can never match.
An example would be
m:0700:0007
.
Examples
take,dironly,./var/vmail/**
take,./var/vmail/**/.*.sieve
./var/vmail/**
This would take all
ā.*.sieveā
files
(or directories) below
/var/vmail
, in all depths,
and all directories there; but no other files.
If your files are at a certain depth, and you donāt
want all other directories taken, too, you can specify that
exactly:
take,dironly,./var/vmail/*
take,dironly,./var/vmail/*/*
take,./var/vmail/*/*/.*.sieve
./var/vmail/**
mode:04:0
take,./etc/
./**
This would take all files from
/etc
, but ignoring
the files that are not world-readable (
other-read
bit cleared); this way only āpublicā files would
get taken.
Author
Generated automatically by Doxygen for fsvs from the source code.