From dc1c8c062c45378c2d912c79497f367e94f56fa0 Mon Sep 17 00:00:00 2001 From: Dmitry Astapov Date: Fri, 30 Aug 2019 14:29:17 +0100 Subject: [PATCH] Reiterate that 'file cache names are absolute' in FAQ (#4738) Reiterate that 'file cache names are absolute' Drive home the point that relative source names does not save you from re-chunking if absolute pathnames change. Also: mention bind mount solution. --- docs/faq.rst | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/docs/faq.rst b/docs/faq.rst index 3ba214031..0788c21c5 100644 --- a/docs/faq.rst +++ b/docs/faq.rst @@ -631,6 +631,9 @@ already used. By default, ctime (change time) is used for the timestamps to have a rather safe change detection (see also the --files-cache option). +Furthermore, pathnames recorded in files cache are always absolute, even if you specify +source directories with relative pathname. If relative pathnames are stable, but absolute are +not (for example if you mount a filesystem without stable mount points for each backup or if you are running the backup from a filesystem snapshot whose name is not stable), borg will assume that files are different and will report them as 'added', even though no new chunks will be actually recorded for them. To avoid this, you could bind mount your source directory in a directory with the stable path. .. _always_chunking: @@ -660,7 +663,8 @@ it would be much faster. Another possible reason is that files don't always have the same path, for example if you mount a filesystem without stable mount points for each backup or if you are running the backup from a filesystem snapshot whose name is not stable. If the directory where you mount a filesystem is different every time, -Borg assume they are different files. +Borg assumes they are different files. This is true even if you backup these files with relative pathnames - borg uses full +pathnames in files cache regardless. Is there a way to limit bandwidth with Borg?