[Box Backup] Hard Links & Ignoring directories

[Chris Wilson]

Hi Ben,

On Sun, 21 Jun 2009, Ben Bennett wrote:

> Thanks for the excellent software.
>
> I have two odd questions after upgrading to a recent trunk version of 
> boxbackup.  Now I see:
>
> Jun 21 22:23:42 ayup bbackupd[24222]: WARNING: Found conflicting parent 
> ID for file ID 1579976 (/home/fiji/public_html/pictures/49/014 - 
> Nursery.jpg): expected 34689 but found 69964 (same directory used in two 
> different locations?)
>
> The warning is correct, the file is in two locations...
>
>> ls -li '/home/fiji/public_html/pictures/49/013 - Nursery.jpg' '/home/fiji/public_html/family/3/013 - Nursery.jpg'
> 1579975 -rw-r--r-- 2 fiji fiji 131622 2002-12-18 07:37 /home/fiji/public_html/family/3/013 - Nursery.jpg
> 1579975 -rw-r--r-- 2 fiji fiji 131622 2002-12-18 07:37 /home/fiji/public_html/pictures/49/013 - Nursery.jpg
>
> I see no reason why hard links should be discouraged... if box can not 
> store that relationship, fine (not great though).  But how can I at 
> least supress the warning?

I agree that hard links should be supported, and that this is a bug. 
Please could you get an account in the bug tracker and file a bug?

The reasons for this warning are:

1. Almost nobody uses hard links on their data files, so nobody has 
reported this problem before.

2. Including the same files in two backup locations (not two directories) 
is an error and a waste of bandwidth.

3. There was a bug on Windows where file IDs were being duplicated all the 
time, which was only spotted because I added this warning.

4. Box Backup uses file IDs to track renaming of files. If you use hard 
links then this will not work correctly and will cause your files to be 
renamed between the two directories all the time. This is the real bug.

> Question the second.  I keep getting: Jun 21 22:24:56 ayup 
> bbackupd[24222]: WARNING: Failed to access file: /home/jb/.gvfs: 
> Permission denied
>
> Which while true is irritating because I have:

Thanks for the report. Should be fixed now. Please could you try updating 
to the latest trunk version and see if that fixes this problem?

> BTW, is there any advantage to combining it all into one regexp, or
> should I just have multiple lines?

It's very slightly more efficient, but much less readable, so unless you 
can see a strong CPU time advantage I'd advise you to use separate 
ExcludeDir entries instead. This also doesn't require you to use regular 
expressions to compare them, so it may even be faster.

Cheers, Chris.
-- 
_ ___ __     _
  / __/ / ,__(_)_  | Chris Wilson <0000 at qwirx.com> - Cambs UK |
/ (_/ ,\/ _/ /_ \ | Security/C/C++/Java/Perl/SQL/HTML Developer |
\ _/_/_/_//_/___/ | We are GNU-free your mind-and your software |