Comment 11 for bug 412470

Revision history for this message
Borph (borph) wrote : Re: [Bug 412470] Re: hardlinking doesnt work from cronjob with schedule per included folder enabled

Hi,

> Some strange things I notice: your includes and excludes are a bit weird
> like:
> --exclude="/home/peter/BiTtest" --include="/home/peter/BiTtest/subfolder/**"
> Should not mention the exclude... oh wait it should mention it if the folder
> that should only be backupped once every year or something is a subfolder of
> a folder that should be backupped every 10 minutes, it should exclude it.

I think you confused it, didn't you? The subfolder has the higher
frequency than the parent folder in my example. If they are disjoint,
it makes sense to exclude the one with the lower frequency of course,
so it doesn't get rsync'ed. But here they are not disjoint.

> What does not on the other hand is the cp -alb function for a folder it
> already copied, anyway, actually what is the whole reason for this command,
> ignored folders are copied anyway during the hardlinking?

I think it tries to hardlink in two steps: one before the rsync and
one after. Before, the folders are hardlinked, which are going to be
rsync'ed, after the other folders are, which should not be included in
the rsync (because of their low frequency).

> The backup dir has grown incredibly in size, however I do not see the ~
> behaviour yet. What I do see is time consumption, and size consumption.

This fits. I think the *~ files are a symptom on my machine. Your cp
-alb command behaves different. Mine detects that file3.txt already
exists and makes a copy to file3.txt~ (link-count 1), then it
hard-links file3.txt from source again.

>> -r--r--r-- 2 peter peter 11 2009-08-31 20:36 file3.txt <== linked from 20090831-204500, old! wrong!
>> -r--r--r-- 1 peter peter 12 2009-08-31 20:41 file3.txt~ <== that was rsync'ed, but cp made a backup after

In fact, now at work I tried to reproduce the behaviour of cp -alb and
I couldn't! Its a Fedora box, and it makes the ~ files if the
destination exists and has no relation, but if source and destination
are actually links to the same file, it does nothing. I think at home
this was different.

Anyway, as with a changed and rsync'ed file the source and destination
are not the same, the intended behaviour of cp -alb is wrong anyway
(on my box its wrong on even any file).

==> schedules per include-folder are broken indeed.