I did some tests with Sidux. Indeed the latest update is 3.0.7.
It seems that the problem is related to rsync.
On my system with 3.0.6 the bug is there but using "--delete-before" as
workaround works for me. On the other hand --delete-before is slower and use
more memory because it does not use incremental mode. So I prefer to stick with
"--delete" option.
>From rsync man page:
"
--delete
This tells rsync to delete extraneous files from the receiving
side (ones that aren't on the sending
side), but only for the directories that are being synchronized.
You must have asked rsync to send the
whole directory (e.g. “dir” or “dir/”) without using a
wildcard for the directory's contents (e.g.
“dir/*”) since the wildcard is expanded by the shell and rsync
thus gets a request to transfer individ‐
ual files, not the files' parent directory. Files that
are excluded from the transfer are also
excluded from being deleted unless you use the --delete-excluded
option or mark the rules as only
matching on the sending side (see the include/exclude modifiers
in the FILTER RULES section).
Prior to rsync 2.6.7, this option would have no effect unless
--recursive was enabled. Beginning with
2.6.7, deletions will also occur when --dirs (-d) is enabled, but
only for directories whose contents
are being copied.
This option can be dangerous if used incorrectly! It is a very
good idea to first try a run using the
--dry-run option (-n) to see what files are going to be deleted.
If the sending side detects any I/O errors, then the deletion of
any files at the destination will be
automatically disabled. This is to prevent temporary
filesystem failures (such as NFS errors) on the
sending side causing a massive deletion of files on the
destination. You can override this with the
--ignore-errors option.
The --delete option may be combined with one of the
--delete-WHEN options without conflict, as well as
--delete-excluded. However, if none of the --delete-WHEN options
are specified, rsync will choose the
--delete-during algorithm when talking to rsync 3.0.0 or newer,
and the --delete-before algorithm when
talking to an older rsync. See also --delete-delay and
--delete-after.
"
The problem appears only if I include /etc as a regular user and I don't
have the right to explore everything. This may happen to all folders I
don't have enough rights.
If I run BIT as root if works as expected.
--
Deleted Files are stored in snapshots forever
https://bugs.launchpad.net/bugs/406092
You received this bug notification because you are a member of Back In
Time Team, which is subscribed to Back In Time.
Status in Back In Time: Fix Committed
Bug description:
The classic example of this is when Back In Time backs up your desktop.
For example.
I create a file called 'foo' on my desktop to write some quick notes in.
I create a snapshot, and '~/Desktop/foo' is now stored in 'Snapshot1'.
I delete 'foo' from my Desktop, as I no longer need the file.
I create another snapshot 'Snapshot2'. 'Foo' is still listed in 'Snapshot2' as
a file (although obviously it hasn't changed).
For each snapshot that is taken after this, 'foo' will always be listed as a
file in the snapshot, and never removed from the series of backups.
What should happen is, 'foo' should be stored in 'Snapshot1', but should not be
stored in 'Snapshot2'.
When 'Snapshot1' is deleted (either manually or automatically), 'foo' is no
longer backed up through back in time, as it no longer exists on the system.
The only current workaround I have found, is manually deleting the files I want
to be removed from snapshots, so they are not included in the next sync.
_______________________________________________
Mailing list: https://launchpad.net/~bit-team
Post to : bit-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~bit-team
More help : https://help.launchpad.net/ListHelp
