From boxbackup-dev@fluffy.co.uk  Mon Dec  4 09:22:02 2006
From: boxbackup-dev@fluffy.co.uk (Ben Summers)
Date: Mon, 4 Dec 2006 09:22:02 +0000
Subject: [Box Backup-dev] Only half a million dollars?
Message-ID: <43066442-A0D7-4C4F-9927-BA3C9C5FDE13@fluffy.co.uk>

http://ohloh.net/projects/3723

I like the 'factoid':

   "The source code has a large number of comments relative to other  
C/C++ projects."




From boxbackup-dev@fluffy.co.uk  Mon Dec  4 09:52:49 2006
From: boxbackup-dev@fluffy.co.uk (Martin Ebourne)
Date: Mon, 04 Dec 2006 09:52:49 +0000
Subject: [Box Backup-dev] Only half a million dollars?
In-Reply-To: <43066442-A0D7-4C4F-9927-BA3C9C5FDE13@fluffy.co.uk>
References: <43066442-A0D7-4C4F-9927-BA3C9C5FDE13@fluffy.co.uk>
Message-ID: <20061204095249.mwy4493dbsw0wogk@ebourne.me.uk>

Ben Summers <ben@fluffy.co.uk> wrote:
> http://ohloh.net/projects/3723
>
> I like the 'factoid':
>
>   "The source code has a large number of comments relative to other =20
> C/C++ projects."

A whole bunch of bizarre conclusions:

   "Ohloh searches the source code for license declarations. Ohloh =20
didn't find any such declarations in this project's source code."

Apparently I've spent nearly 5 months working on Box. Quite probably =20
one month's worth of work, somewhat spread about, but I'm sure I'm =20
well short of five months! Also I'm sure Chris has spent more time on =20
it than me.

Actually I think it's only looking at trunk and not paying any =20
attention to who originally checked the changes in. That's pretty =20
rubbish really. chromi is down for 6 lines!

I do like the little activity graphs though. :)

As for Per's comment ratio being 0% that is very ironic given he's =20
only ever checked in documentation. And I'm sure he'd be interested to =20
know his contribution is worth around $23,000 - if only someone was =20
paying!

Cheers,

Martin.


From boxbackup-dev@fluffy.co.uk  Mon Dec  4 09:56:15 2006
From: boxbackup-dev@fluffy.co.uk (Martin Ebourne)
Date: Mon, 04 Dec 2006 09:56:15 +0000
Subject: [Box Backup-dev] Only half a million dollars?
In-Reply-To: <20061204095249.mwy4493dbsw0wogk@ebourne.me.uk>
References: <43066442-A0D7-4C4F-9927-BA3C9C5FDE13@fluffy.co.uk>
 <20061204095249.mwy4493dbsw0wogk@ebourne.me.uk>
Message-ID: <20061204095615.yix240gz6skkwk88@ebourne.me.uk>

Martin Ebourne <lists@ebourne.me.uk> wrote:
>   "Ohloh searches the source code for license declarations. Ohloh  
> didn't find any such declarations in this project's source code."

Of course, these aren't checked in. I'll give it that one then. :)

Martin.

From boxbackup-dev@fluffy.co.uk  Tue Dec  5 13:51:19 2006
From: boxbackup-dev@fluffy.co.uk (Ben Summers)
Date: Tue, 5 Dec 2006 13:51:19 +0000
Subject: [Box Backup-dev] Timeouts
Message-ID: <6FA5ED6F-1BD0-494B-994B-C010D8F91F41@fluffy.co.uk>

Is it possible to just set really long timeouts on the underlying =20
SSL =10/ TCP/IP sockets?

Ben



From boxbackup-dev@fluffy.co.uk  Thu Dec  7 11:42:35 2006
From: boxbackup-dev@fluffy.co.uk (Martin Ebourne)
Date: Thu, 07 Dec 2006 11:42:35 +0000
Subject: [Box Backup-dev] Timeouts
In-Reply-To: <6FA5ED6F-1BD0-494B-994B-C010D8F91F41@fluffy.co.uk>
References: <6FA5ED6F-1BD0-494B-994B-C010D8F91F41@fluffy.co.uk>
Message-ID: <20061207114235.tn8bz829cs0swc4o@ebourne.me.uk>

Ben Summers <ben@fluffy.co.uk> wrote:
> Is it possible to just set really long timeouts on the underlying =20
> SSL =10/ TCP/IP sockets?

Yes and no. Portability and compatibility is the problem here. On some =20
systems you can (often the default is already 2hrs or so), don't know =20
how to do it in a portable manner.

However, once you bring stateful firewalls into the equation you have =20
more potential problems. Some of these broken firewalls have =20
connection timeouts as low as 5 minutes, and we can't expect all box =20
users to have control over all firewalls on their route.

An alternative is tcp level keepalives. You can do these by setting =20
SO_KEEPALIVE which I think is POSIX. However, controlling how often =20
they occur is somewhat more difficult. eg. On linux you can use the =20
TCP_KEEPIDLE etc socket options, but on some systems its a kernel =20
parameter change.

I've no idea if openssl has anything protocol level we can use here, =20
otherwise the only really portable and controllable way is to do it =20
manually.

Cheers,

Martin.

From boxbackup-dev@fluffy.co.uk  Thu Dec  7 11:56:44 2006
From: boxbackup-dev@fluffy.co.uk (Chris Wilson)
Date: Thu, 7 Dec 2006 11:56:44 +0000 (GMT)
Subject: [Box Backup-dev] Timeouts
In-Reply-To: <20061207114235.tn8bz829cs0swc4o@ebourne.me.uk>
References: <6FA5ED6F-1BD0-494B-994B-C010D8F91F41@fluffy.co.uk>
 <20061207114235.tn8bz829cs0swc4o@ebourne.me.uk>
Message-ID: <Pine.LNX.4.64.0612071151180.9022@rocio.int.aidworld.org>

Hi Martin and Ben,

On Thu, 7 Dec 2006, Martin Ebourne wrote:

> Ben Summers <ben@fluffy.co.uk> wrote:
>> Is it possible to just set really long timeouts on the underlying SSL / 
>> TCP/IP sockets?
[...]
> An alternative is tcp level keepalives. You can do these by setting 
> SO_KEEPALIVE which I think is POSIX. However, controlling how often they 
> occur is somewhat more difficult. eg. On linux you can use the TCP_KEEPIDLE 
> etc socket options, but on some systems its a kernel parameter change.
>
> I've no idea if openssl has anything protocol level we can use here, 
> otherwise the only really portable and controllable way is to do it 
> manually.

I guess there is not a good way to do it at the TCP or SSL level, because 
OpenSSH implements its own mechanism. From ssh_config(5):

ServerAliveInterval

   Sets a timeout interval in seconds after which if no data has been
   received from the server, ssh will send a message through the encrypted
   channel to request a response from the server.
   [...]
   It is important to note that the use of server alive
   messages is very different from TCPKeepAlive (below).  The
   server alive messages are sent through the encrypted channel and
   therefore will not be spoofable.  The TCP keepalive option enabled
   by TCPKeepAlive is spoofable.  The server alive mechanism is
   valuable when the client or server depend on knowing when a
   connection has become inactive.

TCPKeepAlive

   Specifies whether the system should send TCP keepalive messages
   to the other side.  If they are sent, death of the connection or
   crash of one of the machines will be properly noticed.  This
   option only uses TCP keepalives (as opposed to using ssh level
   keepalives), so takes a long time to notice when the connection
   dies.  As such, you probably want the ServerAliveInterval option
   as well. However, this means that connections will die if the
   route is down temporarily, and some people find it annoying.

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 |

From boxbackup-dev@fluffy.co.uk  Thu Dec  7 12:22:47 2006
From: boxbackup-dev@fluffy.co.uk (Ben Summers)
Date: Thu, 7 Dec 2006 12:22:47 +0000
Subject: [Box Backup-dev] Timeouts
Message-ID: <B9CB31E3-CA1A-4D2F-9E5E-A640A59EBDD5@fluffy.co.uk>

On Thu, 7 Dec 2006, Martin Ebourne wrote:

> Ben Summers <ben@fluffy.co.uk> wrote:
>
>> Is it possible to just set really long timeouts on the underlying =20
>> SSL =10/ TCP/IP sockets?
>>
>
> Yes and no. Portability and compatibility is the problem here. On  
> some =20
> systems you can (often the default is already 2hrs or so), don't  
> know =20
> how to do it in a portable manner.

(and Chris said stuff about OpenSSL)


Hmmm. A better plan would seem to be redesigning things to cope  
better with unreliable connections.

1) Gather all changes to send before connecting in the first place  
(from file system notifications or a slow scanning operation)

2) Reconnect and continue when the connection fails.

Ben




From boxbackup-dev@fluffy.co.uk  Thu Dec  7 12:29:31 2006
From: boxbackup-dev@fluffy.co.uk (Chris Wilson)
Date: Thu, 7 Dec 2006 12:29:31 +0000 (GMT)
Subject: [Box Backup-dev] Timeouts
In-Reply-To: <B9CB31E3-CA1A-4D2F-9E5E-A640A59EBDD5@fluffy.co.uk>
References: <B9CB31E3-CA1A-4D2F-9E5E-A640A59EBDD5@fluffy.co.uk>
Message-ID: <Pine.LNX.4.64.0612071226050.9022@rocio.int.aidworld.org>

Hi Ben,

On Thu, 7 Dec 2006, Ben Summers wrote:

> Hmmm. A better plan would seem to be redesigning things to cope better with 
> unreliable connections.
>
> 1) Gather all changes to send before connecting in the first place (from file 
> system notifications or a slow scanning operation)

We can't gather file diffs that way, unless we store the encrypted block 
checksums on the client as well.

And if we did, then it might be a multi-gigabyte set of changes that we'd 
have to store until we connect.

> 2) Reconnect and continue when the connection fails.

Yes, that would be good. How would we handle that? I guess we can't just 
catch the exception and log in again, but it would be nice to be able to 
detect the progress of the upload (maybe store it in the context object) 
and restart from the same position after a failure.

Perhaps if we pushed the stack of pending directory entries into the 
context at each stage, then we'd be able to easily pick up where we left 
off? Would require a bit of rework to do all the readdir()s first.

What's so bad about the new timers implementation and keepalives that I 
spent a month writing, including full unit tests?

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 |

From boxbackup-dev@fluffy.co.uk  Fri Dec  8 12:11:00 2006
From: boxbackup-dev@fluffy.co.uk (Ben Summers)
Date: Fri, 8 Dec 2006 12:11:00 +0000
Subject: [Box Backup-dev] Timeouts
Message-ID: <25BBC7EF-0924-4461-8D31-9DEC2E7FAFAB@fluffy.co.uk>

On Thu, 7 Dec 2006, Chris Wilson wrote:

> On Thu, 7 Dec 2006, Ben Summers wrote:
>
>
>> Hmmm. A better plan would seem to be redesigning things to cope  
>> better with
>> unreliable connections.
>>
>> 1) Gather all changes to send before connecting in the first place  
>> (from file
>> system notifications or a slow scanning operation)
>>
>
> We can't gather file diffs that way, unless we store the encrypted  
> block
> checksums on the client as well.

Sorry, I meant "files which have been changed and need to be  
uploaded" not doing diffs beforehand.

>
> And if we did, then it might be a multi-gigabyte set of changes  
> that we'd
> have to store until we connect.


Diffs are stored as a 'Recipe' and the data built on the fly, so  
they're not that memory intensive. But yes, not the best plan ever.


>
>
>> 2) Reconnect and continue when the connection fails.
>>
>
> Yes, that would be good. How would we handle that? I guess we can't  
> just
> catch the exception and log in again, but it would be nice to be  
> able to
> detect the progress of the upload (maybe store it in the context  
> object)
> and restart from the same position after a failure.
>
> Perhaps if we pushed the stack of pending directory entries into the
> context at each stage, then we'd be able to easily pick up where we  
> left
> off? Would require a bit of rework to do all the readdir()s first.

If we have a prepared list of files to change, we can avoid the  
recursive code.

>
> What's so bad about the new timers implementation and keepalives  
> that I
> spent a month writing, including full unit tests?

Nothing at all. Avoiding the timeout in the first place is far better  
than anything else! Diffing will happen when the connection is open.

Your work is appreciated!

Ben




From boxbackup-dev@fluffy.co.uk  Sat Dec 16 16:23:48 2006
From: boxbackup-dev@fluffy.co.uk (Chris Wilson)
Date: Sat, 16 Dec 2006 16:23:48 +0000 (GMT)
Subject: [Box Backup-dev] Error logging
Message-ID: <Pine.LNX.4.62.0612161617300.30917@top.qwarx.com>

Hi all,

Pete Jalajas just added an interesting request to the FeatureRequests page 
on the Wiki:

"Please add some code to the client to log on what BackupLocation, Path, 
and sub-directory it is working. We had a bbackupd.conf with about 10 
BackupLocations. Another person in the company removed one of those Paths 
without telling us admins, causing the backup to fail with a "permissions" 
error (I think it was Exception: Common OSFileError (Error accessing a 
file. Check permissions.) (1/9)). Because there was no file or directory 
to report as being bad, the log did not report anything except the 
permissions error. (I believe ExtendedLogging was set to Yes, and we still 
did not get any helpful information.) It took us quite a while to delete 
BackupLocations to find which one caused the problem. (Of course, now 
files in all those locations are marked as deleted, ugh.) Had the log 
reported what BackupLocation, Path, or sub-directory it was working on, we 
could have diagnosed the problem more easily. (PeteJ 2006-12-14)"

I consider this a bug, since Box Backup was not working and did not 
provide enough information to help fix the problem. I've committed a fix 
to my merge tree:

[http://bbdev.fluffy.co.uk/trac/changeset/1222]

I know that Martin is against adding random feature requests as bug 
tickets, and I can see why, but in cases like this, I would suggest that 
we encourage people to add them, and that we create a ticket for this one. 
Comments?

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 |


From boxbackup-dev@fluffy.co.uk  Sat Dec 16 20:36:31 2006
From: boxbackup-dev@fluffy.co.uk (Chris Wilson)
Date: Sat, 16 Dec 2006 20:36:31 +0000 (GMT)
Subject: [Box Backup-dev] Logging framework
Message-ID: <Pine.LNX.4.62.0612162030380.30917@top.qwarx.com>

Hi all,

I've implemented a new logging framework as discussed about a year ago, 
and almost exactly as described at 
[http://bbdev.fluffy.co.uk/trac/wiki/LoggingFrameworkProposal].

You can see the classes at:

   [http://bbdev.fluffy.co.uk/svn/box/chris/merge/lib/common/Logging.h]
   [http://bbdev.fluffy.co.uk/svn/box/chris/merge/lib/common/Logging.cpp]

and an example of the changes in practice should eventually appear at:

   [http://bbdev.fluffy.co.uk/trac/changeset/1226]

although Trac seems to be lagging behind the repository, and I'm currently 
getting an error on the timeline page:

   [http://bbdev.fluffy.co.uk/trac/timeline]

> Repository checkins event provider (ChangesetModule) failed:
>
> NoSuchChangeset: No changeset 1224 in the repository"

Comments would be very welcome.

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 |


From boxbackup-dev@fluffy.co.uk  Sat Dec 16 21:32:24 2006
From: boxbackup-dev@fluffy.co.uk (Charles Lecklider)
Date: Sat, 16 Dec 2006 21:32:24 +0000
Subject: [Box Backup-dev] win32 compile problems
Message-ID: <458465E8.6010809@invis.net>

http://bbdev.fluffy.co.uk/svn/box/chris/merge


error C2371: '_ino_t' : redefinition; different basic types
d:\dev\boxbackup\lib\win32\emu.h	line 35


warning C4005: 'O_BINARY' : macro redefinition	e:\program files
(x86)\microsoft visual studio 8\vc\include\fcntl.h	line 75	


warning C4244: '=' : conversion from 'IOStream::pos_type' to 'int',
possible loss of data
d:\dev\boxbackup\lib\common\collectinbufferstream.cpp	164	

(and lines 167 and 170)


warning C4267: 'return' : conversion from 'size_t' to 'unsigned int',
possible loss of data	d:\dev\boxbackup\lib\common\excludelist.h	line 51	


warning C4267: 'initializing' : conversion from 'size_t' to 'int',
possible loss of data	d:\dev\boxbackup\lib\common\archive.h	line 70



warning C4267: 'initializing' : conversion from 'size_t' to 'int',
possible loss of data	d:\dev\boxbackup\lib\common\iostreamgetline.cpp
line 155


warning C4244: '=' : conversion from 'IOStream::pos_type' to 'int',
possible loss of data	d:\dev\boxbackup\lib\common\memblockstream.cpp
line 182	

(and lines 185 and 188)


warning C4267: 'initializing' : conversion from 'size_t' to 'int',
possible loss of data	d:\dev\boxbackup\lib\common\readgatherstream.cpp
line 72


warning C4244: 'initializing' : conversion from 'IOStream::pos_type' to
'int', possible loss of data
d:\dev\boxbackup\lib\common\readgatherstream.cpp	line 148


warning C4244: 'argument' : conversion from 'IOStream::pos_type' to
'size_t', possible loss of data
d:\dev\boxbackup\lib\common\streamablememblock.cpp	line 118


warning C4244: 'argument' : conversion from 'IOStream::pos_type' to
'int', possible loss of data
d:\dev\boxbackup\lib\common\streamablememblock.cpp	line 127


warning C4244: '=' : conversion from 'IOStream::pos_type' to 'int',
possible loss of data
d:\dev\boxbackup\lib\common\streamablememblock.cpp	line 144


warning C4267: 'initializing' : conversion from 'size_t' to 'unsigned
int', possible loss of data	d:\dev\boxbackup\lib\common\utils.cpp	line 42


warning C4267: 'argument' : conversion from 'size_t' to 'unsigned long',
possible loss of data	d:\dev\boxbackup\lib\common\waitforevent.cpp	line 166


warning C4805: '==' : unsafe mix of type 'int8_t' and type 'bool' in
operation	d:\dev\boxbackup\lib\server\protocol.h	line 97


warning C4311: 'type cast' : pointer truncation from 'uint8_t *' to
'unsigned long'	d:\dev\boxbackup\lib\backupclient\backupstorefile.h	line 155


warning C4244: '=' : conversion from 'time_t' to 'long', possible loss
of data	d:\dev\boxbackup\lib\common\boxtimetounix.h	line 29


warning C4267: 'return' : conversion from 'size_t' to 'unsigned int',
possible loss of data	d:\dev\boxbackup\lib\common\excludelist.h	line 51


warning C4805: '==' : unsafe mix of type 'int8_t' and type 'bool' in
operation	d:\dev\boxbackup\lib\server\protocol.h	line 97


warning C4267: 'return' : conversion from 'size_t' to 'unsigned int',
possible loss of data
d:\dev\boxbackup\lib\backupclient\backupstoredirectory.h	line 149


warning C4267: 'initializing' : conversion from 'size_t' to 'int32_t',
possible loss of data
d:\dev\boxbackup\lib\backupclient\backupclientrestore.cpp	line 107	





And lots and lots more....

Am I looking at the wrong branch?

-C


From boxbackup-dev@fluffy.co.uk  Sat Dec 16 21:36:32 2006
From: boxbackup-dev@fluffy.co.uk (Charles Lecklider)
Date: Sat, 16 Dec 2006 21:36:32 +0000
Subject: [Box Backup-dev] win32 compile problems
In-Reply-To: <458465E8.6010809@invis.net>
References: <458465E8.6010809@invis.net>
Message-ID: <458466E0.7080100@invis.net>

I should mention this is with VC2k5 Pro.

-C



From boxbackup-dev@fluffy.co.uk  Sat Dec 16 22:07:41 2006
From: boxbackup-dev@fluffy.co.uk (Chris Wilson)
Date: Sat, 16 Dec 2006 22:07:41 +0000 (GMT)
Subject: [Box Backup-dev] win32 compile problems
In-Reply-To: <458465E8.6010809@invis.net>
References: <458465E8.6010809@invis.net>
Message-ID: <Pine.LNX.4.62.0612162205470.30917@top.qwarx.com>

Hi Charles,

On Sat, 16 Dec 2006, Charles Lecklider wrote:

> http://bbdev.fluffy.co.uk/svn/box/chris/merge
[...]
> Am I looking at the wrong branch?

I haven't finished merging the general branch into trunk, and not all the 
changes are in the merge branch. I have never tried to compile that branch 
on Windows with any compiler, and I doubt that it would work.

Please try the general branch. If something doesn't work, I'll fix it 
there and then merge it back to trunk later.

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 |


From boxbackup-dev@fluffy.co.uk  Sat Dec 16 23:09:20 2006
From: boxbackup-dev@fluffy.co.uk (Charles Lecklider)
Date: Sat, 16 Dec 2006 23:09:20 +0000
Subject: [Box Backup-dev] win32 compile problems
In-Reply-To: <Pine.LNX.4.62.0612162205470.30917@top.qwarx.com>
References: <458465E8.6010809@invis.net> <Pine.LNX.4.62.0612162205470.30917@top.qwarx.com>
Message-ID: <45847CA0.2020603@invis.net>

Chris Wilson wrote:
> Hi Charles,
> 
> On Sat, 16 Dec 2006, Charles Lecklider wrote:
> 
>> http://bbdev.fluffy.co.uk/svn/box/chris/merge
> [...]
>> Am I looking at the wrong branch?
> 
> I haven't finished merging the general branch into trunk, and not all
> the changes are in the merge branch. I have never tried to compile that
> branch on Windows with any compiler, and I doubt that it would work.

OK, no probs - I was hoping it was something like that :-)

> Please try the general branch. If something doesn't work, I'll fix it
> there and then merge it back to trunk later.

warning C4244: '=' : conversion from 'IOStream::pos_type' to 'int',
possible loss of data
d:\dev\boxbackup\lib\common\collectinbufferstream.cpp	 line 164

(and 167 and 170)


warning C4267: 'return' : conversion from 'size_t' to 'unsigned int',
possible loss of data	d:\dev\boxbackup\lib\common\excludelist.h	line 51	


warning C4267: 'initializing' : conversion from 'size_t' to 'int',
possible loss of data	d:\dev\boxbackup\lib\common\archive.h	line 70	


warning C4267: 'initializing' : conversion from 'size_t' to 'int',
possible loss of data	d:\dev\boxbackup\lib\common\fdgetline.cpp	line 172	


warning C4267: 'initializing' : conversion from 'size_t' to 'int',
possible loss of data	d:\dev\boxbackup\lib\common\iostreamgetline.cpp
line 155	


warning C4244: '=' : conversion from 'IOStream::pos_type' to 'int',
possible loss of data	d:\dev\boxbackup\lib\common\memblockstream.cpp
line 182	


warning C4244: '=' : conversion from 'IOStream::pos_type' to 'int',
possible loss of data	d:\dev\boxbackup\lib\common\memblockstream.cpp
line 185	


warning C4244: '=' : conversion from 'IOStream::pos_type' to 'int',
possible loss of data	d:\dev\boxbackup\lib\common\memblockstream.cpp
line 188	


warning C4267: 'initializing' : conversion from 'size_t' to 'int',
possible loss of data
d:\dev\boxbackup\lib\common\readgatherstream.cpp	line 72	


warning C4244: 'initializing' : conversion from 'IOStream::pos_type' to
'int', possible loss of data
d:\dev\boxbackup\lib\common\readgatherstream.cpp	line 148	


warning C4244: 'argument' : conversion from 'IOStream::pos_type' to
'size_t', possible loss of data
d:\dev\boxbackup\lib\common\streamablememblock.cpp	line 118	



And lots and lots more....

I have "detect 64-bit portability issues" enabled which isn't part of VC
Express, and I suspect that a lot of these are related to that.

However, since I intend to produce a 64-bit Windows version it's
probably a good idea to fix these :-)

-C


From boxbackup-dev@fluffy.co.uk  Sat Dec 16 23:13:02 2006
From: boxbackup-dev@fluffy.co.uk (Chris Wilson)
Date: Sat, 16 Dec 2006 23:13:02 +0000 (GMT)
Subject: [Box Backup-dev] win32 compile problems
In-Reply-To: <45847CA0.2020603@invis.net>
References: <458465E8.6010809@invis.net> <Pine.LNX.4.62.0612162205470.30917@top.qwarx.com>
 <45847CA0.2020603@invis.net>
Message-ID: <Pine.LNX.4.62.0612162311300.30917@top.qwarx.com>

Hi Charles,

On Sat, 16 Dec 2006, Charles Lecklider wrote:

> warning C4244: '=' : conversion from 'IOStream::pos_type' to 'int',
> possible loss of data
> d:\dev\boxbackup\lib\common\collectinbufferstream.cpp	 line 164
>
> (and 167 and 170)
[...]
> I have "detect 64-bit portability issues" enabled which isn't part of VC
> Express, and I suspect that a lot of these are related to that.

I think it is in VC express. I tried enabling it and fixing the issues it 
threw up, around this time last year, but I managed to break Box in the 
process so the fixes were necer committed.

> However, since I intend to produce a 64-bit Windows version it's 
> probably a good idea to fix these :-)

Indeed. Did it throw up any fatal errors?

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 |


From boxbackup-dev@fluffy.co.uk  Sun Dec 17 10:26:36 2006
From: boxbackup-dev@fluffy.co.uk (James O'Gorman)
Date: Sun, 17 Dec 2006 10:26:36 +0000
Subject: [Box Backup-dev] Logging framework
In-Reply-To: <Pine.LNX.4.62.0612162030380.30917@top.qwarx.com>
References: <Pine.LNX.4.62.0612162030380.30917@top.qwarx.com>
Message-ID: <20061217102636.GA35329@netinertia.co.uk>

Hi Chris,

On Sat, Dec 16, 2006 at 08:36:31PM +0000, Chris Wilson wrote:
> although Trac seems to be lagging behind the repository, and I'm currently 
> getting an error on the timeline page:
> 
>   [http://bbdev.fluffy.co.uk/trac/timeline]
> 
> >Repository checkins event provider (ChangesetModule) failed:
> >
> >NoSuchChangeset: No changeset 1224 in the repository"

This is a bug in Trac introduced in 0.10.1. 0.10.3 recently came out
which supposedly fixes that, so I'll try and upgrade when I've got time
(I'm about to fly out to Milan for a week so might not get a chance
until after Christmas...)

James

From boxbackup-dev@fluffy.co.uk  Sun Dec 17 14:32:13 2006
From: boxbackup-dev@fluffy.co.uk (Charles Lecklider)
Date: Sun, 17 Dec 2006 14:32:13 +0000
Subject: [Box Backup-dev] win32 compile problems
In-Reply-To: <Pine.LNX.4.62.0612162311300.30917@top.qwarx.com>
References: <458465E8.6010809@invis.net> <Pine.LNX.4.62.0612162205470.30917@top.qwarx.com> <45847CA0.2020603@invis.net> <Pine.LNX.4.62.0612162311300.30917@top.qwarx.com>
Message-ID: <458554ED.6030807@invis.net>

Chris Wilson wrote:
> Hi Charles,
> 
> On Sat, 16 Dec 2006, Charles Lecklider wrote:
> 
>> warning C4244: '=' : conversion from 'IOStream::pos_type' to 'int',
>> possible loss of data
>> d:\dev\boxbackup\lib\common\collectinbufferstream.cpp     line 164
>>
>> (and 167 and 170)
> [...]
>> I have "detect 64-bit portability issues" enabled which isn't part of VC
>> Express, and I suspect that a lot of these are related to that.
> 
> I think it is in VC express. I tried enabling it and fixing the issues
> it threw up, around this time last year, but I managed to break Box in
> the process so the fixes were necer committed.

Must have missed it. Still, since I'm using the full version now that's
not important.

>> However, since I intend to produce a 64-bit Windows version it's
>> probably a good idea to fix these :-)
> 
> Indeed. Did it throw up any fatal errors?

The compiler didn't, no, but looking through the list I can see that
some of them have the potential to become "fatal" at runtime in a 64-bit
version. e.g. DWORD vs. size_t.

-C


From boxbackup-dev@fluffy.co.uk  Tue Dec 19 10:36:00 2006
From: boxbackup-dev@fluffy.co.uk (Martin Ebourne)
Date: Tue, 19 Dec 2006 10:36:00 +0000
Subject: [Box Backup-dev] Error logging
In-Reply-To: <Pine.LNX.4.62.0612161617300.30917@top.qwarx.com>
References: <Pine.LNX.4.62.0612161617300.30917@top.qwarx.com>
Message-ID: <20061219103600.c2ov1tg54iokcc4w@ebourne.me.uk>

Chris Wilson <chris@qwirx.com> wrote:
> "Please add some code to the client to log on what BackupLocation, =20
> Path, and sub-directory it is working. We had a bbackupd.conf with =20
> <...>
>
> I consider this a bug, since Box Backup was not working and did not =20
> provide enough information to help fix the problem. I've committed a =20
> fix to my merge tree:
>
> [http://bbdev.fluffy.co.uk/trac/changeset/1222]
>
> I know that Martin is against adding random feature requests as bug =20
> tickets, and I can see why, but in cases like this, I would suggest =20
> that we encourage people to add them, and that we create a ticket =20
> for this one. Comments?

Yes, I am against people adding random feature requests in trac, but =20
if there is a feature that one of the box developers is definitely =20
planning to implement then trac is the right place to record this and =20
track it - a task ticket type is best for this. (You'll see I have a =20
couple like this assigned to me already.)

This one is on the fringe between bug and feature request - the code =20
is not broken because it is working as designed, but this is =20
definitely undesirable behaviour. I think an error handling revamp =20
would be an important improvement in the next major version.

It is a good idea for people adding feature requests on the wiki to =20
drop an email to the box list to alert people to the idea. I've =20
updated the TicketHowto to suggest this.

Cheers,

Martin.

From boxbackup-dev@fluffy.co.uk  Sun Dec 24 12:14:22 2006
From: boxbackup-dev@fluffy.co.uk (James O'Gorman)
Date: Sun, 24 Dec 2006 12:14:22 +0000
Subject: [Box Backup-dev] Logging framework
In-Reply-To: <20061217102636.GA35329@netinertia.co.uk>
References: <Pine.LNX.4.62.0612162030380.30917@top.qwarx.com> <20061217102636.GA35329@netinertia.co.uk>
Message-ID: <20061224121422.GA35890@netinertia.co.uk>

On Sun, Dec 17, 2006 at 10:26:36AM +0000, James O'Gorman wrote:
> On Sat, Dec 16, 2006 at 08:36:31PM +0000, Chris Wilson wrote:
> > although Trac seems to be lagging behind the repository, and I'm currently 
> > getting an error on the timeline page:
> > 
> >   [http://bbdev.fluffy.co.uk/trac/timeline]
> > 
> > >Repository checkins event provider (ChangesetModule) failed:
> > >
> > >NoSuchChangeset: No changeset 1224 in the repository"
> 
> This is a bug in Trac introduced in 0.10.1. 0.10.3 recently came out
> which supposedly fixes that, so I'll try and upgrade when I've got time
> (I'm about to fly out to Milan for a week so might not get a chance
> until after Christmas...)

I've updated Trac to 0.10.3 now so hopefully that "No such changeset"
error will disappear...

James

From boxbackup-dev@fluffy.co.uk  Sun Dec 24 12:51:57 2006
From: boxbackup-dev@fluffy.co.uk (Chris Wilson)
Date: Sun, 24 Dec 2006 12:51:57 +0000 (GMT)
Subject: [Box Backup-dev] Logging framework
In-Reply-To: <20061224121422.GA35890@netinertia.co.uk>
References: <Pine.LNX.4.62.0612162030380.30917@top.qwarx.com>
 <20061217102636.GA35329@netinertia.co.uk> <20061224121422.GA35890@netinertia.co.uk>
Message-ID: <Pine.LNX.4.64.0612241251040.3591@rocio.int.aidworld.org>

Hi James,

On Sun, 24 Dec 2006, James O'Gorman wrote:

> I've updated Trac to 0.10.3 now so hopefully that "No such changeset" 
> error will disappear...

Great, thanks for that.

Any idea why Trac is (or was, I haven't checked) lagging behing subversion 
by a few minutes, maybe half an hour?

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 |

From boxbackup-dev@fluffy.co.uk  Sun Dec 24 13:16:07 2006
From: boxbackup-dev@fluffy.co.uk (James O'Gorman)
Date: Sun, 24 Dec 2006 13:16:07 +0000
Subject: [Box Backup-dev] Logging framework
In-Reply-To: <Pine.LNX.4.64.0612241251040.3591@rocio.int.aidworld.org>
References: <Pine.LNX.4.62.0612162030380.30917@top.qwarx.com> <20061217102636.GA35329@netinertia.co.uk> <20061224121422.GA35890@netinertia.co.uk> <Pine.LNX.4.64.0612241251040.3591@rocio.int.aidworld.org>
Message-ID: <20061224131607.GB35890@netinertia.co.uk>

On Sun, Dec 24, 2006 at 12:51:57PM +0000, Chris Wilson wrote:
> Any idea why Trac is (or was, I haven't checked) lagging behing subversion 
> by a few minutes, maybe half an hour?

Not sure to be honest. When did you last see this?

James

From boxbackup-dev@fluffy.co.uk  Tue Dec 26 12:27:15 2006
From: boxbackup-dev@fluffy.co.uk (Andrei)
Date: Tue, 26 Dec 2006 14:27:15 +0200
Subject: [Box Backup-dev] Using box-backup without daemon, via a remote shell (like rsync)
Message-ID: <bab9f1d50612260427p44160fc6o12e2780d379897c9@mail.gmail.com>

------=_Part_82898_16219514.1167136035619
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hello,

I think it would be useful if the box-backup client could connect to a linux
server via a standard ssh connection on port 22 (using linux username and
password), and then communicate with the box-backup server via pipes (so no
network connections will be involved).

This would help using box-backup on servers that do not allow listening
daemons or persistent processes but do allow connecting through ssh. The
box-backup server maintenance could be executed manually through a cronjob.

Is this possible in the current version? Is this planned for a future
version?

If not, would you estimate it would be hard (if I try to do it) to adapt
box-backup to function in this mode? Any pointers on where should I start if
I try to do this?

Thanks,
Andrei

------=_Part_82898_16219514.1167136035619
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hello,<br><br>I think it would be useful if the box-backup client could connect to a linux server via a standard ssh connection on port 22 (using linux username and password), and then communicate with the box-backup server via pipes (so no network connections will be involved).
<br><br>This would help using box-backup on servers that do not allow listening daemons or persistent processes but do allow connecting through ssh. The box-backup server maintenance could be executed manually through a cronjob.
<br><br>Is this possible in the current version? Is this planned for a future version?<br><br>If not, would you estimate it would be hard (if I try to do it) to adapt box-backup to function in this mode? Any pointers on where should I start if I try to do this?
<br><br>Thanks,<br>Andrei<br>

------=_Part_82898_16219514.1167136035619--

From boxbackup-dev@fluffy.co.uk  Tue Dec 26 12:56:33 2006
From: boxbackup-dev@fluffy.co.uk (Martin Ebourne)
Date: Tue, 26 Dec 2006 12:56:33 +0000
Subject: [Box Backup-dev] Using box-backup without daemon, via a remote
 shell (like rsync)
In-Reply-To: <bab9f1d50612260427p44160fc6o12e2780d379897c9@mail.gmail.com>
References: <bab9f1d50612260427p44160fc6o12e2780d379897c9@mail.gmail.com>
Message-ID: <1167137793.3727.3.camel@avenin.ebourne.me.uk>

On Tue, 2006-12-26 at 14:27 +0200, Andrei wrote:
> I think it would be useful if the box-backup client could connect to a
> linux server via a standard ssh connection on port 22 (using linux
> username and password), and then communicate with the box-backup
> server via pipes (so no network connections will be involved). 
> 
> This would help using box-backup on servers that do not allow
> listening daemons or persistent processes but do allow connecting
> through ssh. The box-backup server maintenance could be executed
> manually through a cronjob. 
> 
> Is this possible in the current version? Is this planned for a future
> version?

You can do this using ssh port forwarding already, although that is
obviously a bit of work to set up.

There is no plan to implement this so far as I am aware of. Assuming
such a patch to do this didn't add too much complexity I might be
interested in it.

Cheers,

Martin.


From boxbackup-dev@fluffy.co.uk  Tue Dec 26 18:37:35 2006
From: boxbackup-dev@fluffy.co.uk (Chris Wilson)
Date: Tue, 26 Dec 2006 18:37:35 +0000 (GMT)
Subject: [Box Backup-dev] Using box-backup without daemon, via a remote
 shell (like rsync)
In-Reply-To: <1167137793.3727.3.camel@avenin.ebourne.me.uk>
References: <bab9f1d50612260427p44160fc6o12e2780d379897c9@mail.gmail.com>
 <1167137793.3727.3.camel@avenin.ebourne.me.uk>
Message-ID: <Pine.LNX.4.64.0612261835170.29554@rocio.int.aidworld.org>

Hi Martin,

On Tue, 26 Dec 2006, Martin Ebourne wrote:
> On Tue, 2006-12-26 at 14:27 +0200, Andrei wrote:
>> I think it would be useful if the box-backup client could connect to a
>> linux server via a standard ssh connection on port 22 (using linux
>> username and password), and then communicate with the box-backup
>> server via pipes (so no network connections will be involved).
>>
>> This would help using box-backup on servers that do not allow
>> listening daemons or persistent processes but do allow connecting
>> through ssh. The box-backup server maintenance could be executed
>> manually through a cronjob.
>
> You can do this using ssh port forwarding already, although that is 
> obviously a bit of work to set up.

Unfortunately that doesn't work if daemons are not allowed on the remote 
host. Although you could start the store daemon when the backup starts and 
kill it afterwards.

Another way might be to mount the remote storage box using sshfs on the 
client, and run the store and backup daemons on the client.

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 |

From boxbackup-dev@fluffy.co.uk  Tue Dec 26 18:41:43 2006
From: boxbackup-dev@fluffy.co.uk (Chris Wilson)
Date: Tue, 26 Dec 2006 18:41:43 +0000 (GMT)
Subject: [Box Backup-dev] Logging framework
In-Reply-To: <20061224131607.GB35890@netinertia.co.uk>
References: <Pine.LNX.4.62.0612162030380.30917@top.qwarx.com>
 <20061217102636.GA35329@netinertia.co.uk> <20061224121422.GA35890@netinertia.co.uk>
 <Pine.LNX.4.64.0612241251040.3591@rocio.int.aidworld.org>
 <20061224131607.GB35890@netinertia.co.uk>
Message-ID: <Pine.LNX.4.64.0612261840310.29554@rocio.int.aidworld.org>

Hi James,

On Sun, 24 Dec 2006, James O'Gorman wrote:

> On Sun, Dec 24, 2006 at 12:51:57PM +0000, Chris Wilson wrote:
>> Any idea why Trac is (or was, I haven't checked) lagging behing subversion
>> by a few minutes, maybe half an hour?
>
> Not sure to be honest. When did you last see this?

Last time I checked in, a few days ago, but when the older version was 
running. Will keep an eye out during the next checkin. How does Trac keep 
synced with the Subversion repo? Does it rely on a hook, or does it read 
from the live repo?

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 |

From boxbackup-dev@fluffy.co.uk  Tue Dec 26 19:05:00 2006
From: boxbackup-dev@fluffy.co.uk (Andrei)
Date: Tue, 26 Dec 2006 21:05:00 +0200
Subject: [Box Backup-dev] Using box-backup without daemon, via a remote shell (like rsync)
In-Reply-To: <Pine.LNX.4.64.0612261835170.29554@rocio.int.aidworld.org>
References: <bab9f1d50612260427p44160fc6o12e2780d379897c9@mail.gmail.com>
 <1167137793.3727.3.camel@avenin.ebourne.me.uk>
 <Pine.LNX.4.64.0612261835170.29554@rocio.int.aidworld.org>
Message-ID: <bab9f1d50612261105n49059fgb3a1f9390a45da68@mail.gmail.com>

------=_Part_86479_12847168.1167159900203
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Thanks for the suggestions.
I managed to connect to the server (box-backup server listening on localhost
instead of the public interface of the server):

I ran in Cygwin:

ssh -L 2201:localhost:2201 user@server.com

Then I ran in the connected shell:

bbstored bbstored.conf SINGLEPROCESS

Then I connected the client to localhost:2201.

I could now write a script to automate this process.

Now the only problem is that I don't know how to stop the bbstored started
in SINGLEPROCESS mode.
Is it OK to use a Ctrl-C ? Can something bad happen if you interrupt it like
this while the server is doing some processing ? Are signals handled ?

I'll also try the sshfs way.

Thanks,
Andrei

On 12/26/06, Chris Wilson <chris@qwirx.com> wrote:
>
> Hi Martin,
>
> On Tue, 26 Dec 2006, Martin Ebourne wrote:
> > On Tue, 2006-12-26 at 14:27 +0200, Andrei wrote:
> >> I think it would be useful if the box-backup client could connect to a
> >> linux server via a standard ssh connection on port 22 (using linux
> >> username and password), and then communicate with the box-backup
> >> server via pipes (so no network connections will be involved).
> >>
> >> This would help using box-backup on servers that do not allow
> >> listening daemons or persistent processes but do allow connecting
> >> through ssh. The box-backup server maintenance could be executed
> >> manually through a cronjob.
> >
> > You can do this using ssh port forwarding already, although that is
> > obviously a bit of work to set up.
>
> Unfortunately that doesn't work if daemons are not allowed on the remote
> host. Although you could start the store daemon when the backup starts and
> kill it afterwards.
>
> Another way might be to mount the remote storage box using sshfs on the
> client, and run the store and backup daemons on the client.
>
> 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 |
> _______________________________________________
> Boxbackup-dev mailing list
> Boxbackup-dev@fluffy.co.uk
> http://lists.warhead.org.uk/mailman/listinfo/boxbackup-dev
>

------=_Part_86479_12847168.1167159900203
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Thanks for the suggestions.<br>I managed to connect to the server (box-backup server listening on localhost instead of the public interface of the server):<br><br>I ran in Cygwin:<br><br>ssh -L 2201:localhost:2201 <a href="mailto:user@server.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">

user@server.com</a><br><br>Then I ran in the connected shell:<br><br>bbstored bbstored.conf SINGLEPROCESS<br><br>Then I connected the client to localhost:2201.<br><br>I could now write a script to automate this process.<br>

<br>Now the only problem is that I don&#39;t know how to stop the bbstored started in SINGLEPROCESS mode.<br>Is
it OK to use a Ctrl-C ? Can something bad happen if you interrupt it
like this while the server is doing some processing ? Are signals
handled ?
<br><br>I&#39;ll also try the sshfs way.<br><br>Thanks,<br><span class="sg">Andrei</span><br><br><div><span class="gmail_quote">On 12/26/06, <b class="gmail_sendername">Chris Wilson</b> &lt;<a href="mailto:chris@qwirx.com">
chris@qwirx.com</a>&gt; wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Hi Martin,<br><br>On Tue, 26 Dec 2006, Martin Ebourne wrote:
<br>&gt; On Tue, 2006-12-26 at 14:27 +0200, Andrei wrote:<br>&gt;&gt; I think it would be useful if the box-backup client could connect to a<br>&gt;&gt; linux server via a standard ssh connection on port 22 (using linux<br>
&gt;&gt; username and password), and then communicate with the box-backup<br>&gt;&gt; server via pipes (so no network connections will be involved).<br>&gt;&gt;<br>&gt;&gt; This would help using box-backup on servers that do not allow
<br>&gt;&gt; listening daemons or persistent processes but do allow connecting<br>&gt;&gt; through ssh. The box-backup server maintenance could be executed<br>&gt;&gt; manually through a cronjob.<br>&gt;<br>&gt; You can do this using ssh port forwarding already, although that is
<br>&gt; obviously a bit of work to set up.<br><br>Unfortunately that doesn&#39;t work if daemons are not allowed on the remote<br>host. Although you could start the store daemon when the backup starts and<br>kill it afterwards.
<br><br>Another way might be to mount the remote storage box using sshfs on the<br>client, and run the store and backup daemons on the client.<br><br>Cheers, Chris.<br>--<br>_ ___ __&nbsp;&nbsp;&nbsp;&nbsp; _<br>&nbsp;&nbsp;/ __/ / ,__(_)_&nbsp;&nbsp;| Chris Wilson &lt;0000 at 
<a href="http://qwirx.com">qwirx.com</a>&gt; - Cambs UK |<br>/ (_/ ,\/ _/ /_ \ | Security/C/C++/Java/Perl/SQL/HTML Developer |<br>\ _/_/_/_//_/___/ | We are GNU-free your mind-and your software |<br>_______________________________________________
<br>Boxbackup-dev mailing list<br><a href="mailto:Boxbackup-dev@fluffy.co.uk">Boxbackup-dev@fluffy.co.uk</a><br><a href="http://lists.warhead.org.uk/mailman/listinfo/boxbackup-dev">http://lists.warhead.org.uk/mailman/listinfo/boxbackup-dev
</a><br></blockquote></div><br>

------=_Part_86479_12847168.1167159900203--

From boxbackup-dev@fluffy.co.uk  Tue Dec 26 23:18:19 2006
From: boxbackup-dev@fluffy.co.uk (Scott McNee)
Date: Wed, 27 Dec 2006 09:18:19 +1000
Subject: [Box Backup-dev] Using box-backup without daemon, via a remote shell (like rsync)
In-Reply-To: <Pine.LNX.4.64.0612261835170.29554@rocio.int.aidworld.org>
References: <bab9f1d50612260427p44160fc6o12e2780d379897c9@mail.gmail.com>
 <1167137793.3727.3.camel@avenin.ebourne.me.uk>
 <Pine.LNX.4.64.0612261835170.29554@rocio.int.aidworld.org>
Message-ID: <6f3f5ff70612261518o1540957etfcf4f6b7fa89b1c4@mail.gmail.com>

------=_Part_68708_2816753.1167175099163
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi Guys

An alternative to sshfs would to to use rsync as has been discussed many
times to backup the bbstored store. This has the benefit of partial /
resumable transfers and has been tested successfully with box.


(Rsync can be configured to run in the foreground if I remember correctly.)

BTW Merry xmas and other such things.
Thank you all for your hardwork this year. I am eagerly awaiting the next
release of box with all it's enhancements.



On 27/12/06, Chris Wilson <chris@qwirx.com> wrote:
>
> Hi Martin,
>
> On Tue, 26 Dec 2006, Martin Ebourne wrote:
> > On Tue, 2006-12-26 at 14:27 +0200, Andrei wrote:
> >> I think it would be useful if the box-backup client could connect to a
> >> linux server via a standard ssh connection on port 22 (using linux
> >> username and password), and then communicate with the box-backup
> >> server via pipes (so no network connections will be involved).
> >>
> >> This would help using box-backup on servers that do not allow
> >> listening daemons or persistent processes but do allow connecting
> >> through ssh. The box-backup server maintenance could be executed
> >> manually through a cronjob.
> >
> > You can do this using ssh port forwarding already, although that is
> > obviously a bit of work to set up.
>
> Unfortunately that doesn't work if daemons are not allowed on the remote
> host. Although you could start the store daemon when the backup starts and
> kill it afterwards.
>
> Another way might be to mount the remote storage box using sshfs on the
> client, and run the store and backup daemons on the client.
>
> 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 |
> _______________________________________________
> Boxbackup-dev mailing list
> Boxbackup-dev@fluffy.co.uk
> http://lists.warhead.org.uk/mailman/listinfo/boxbackup-dev
>



-- 
Thank you.

Scott McNee
Manager

M : 0415 10 44 10
T : 07 3274 3933
E : scott@bizebox.com.au

"backing up your business"
http://www.bizebox.com.au

DISCLAIMER
This transmission is confidential and intended for the addressee only. If
you have received it in error, please delete it and notify the sender.
Unless explicitly attributed, the opinions expressed in this E-mail are
those of the author only and do not represent the official view of bizEbox.
bizEbox checks all inbound/outbound e-mail for Viruses. However, we advise
that this e-mail and any attached files should be re-scanned to detect
viruses. bizEbox accepts no liability for loss or damage (whether caused by
negligence or not) resulting from the use of this or any attached files.

------=_Part_68708_2816753.1167175099163
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi Guys <br><br>An alternative to sshfs would to to use rsync as has been discussed many times to backup the bbstored store. This has the benefit of partial / resumable transfers and has been tested successfully with box.<br>
<br><br>(Rsync can be configured to run in the foreground if I remember correctly.)<br><br>BTW Merry xmas and other such things.<br>Thank you all for your hardwork this year. I am eagerly awaiting the next release of box with all it&#39;s enhancements.
<br><br><br><br><div><span class="gmail_quote">On 27/12/06, <b class="gmail_sendername">Chris Wilson</b> &lt;<a href="mailto:chris@qwirx.com">chris@qwirx.com</a>&gt; wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi Martin,<br><br>On Tue, 26 Dec 2006, Martin Ebourne wrote:<br>&gt; On Tue, 2006-12-26 at 14:27 +0200, Andrei wrote:<br>&gt;&gt; I think it would be useful if the box-backup client could connect to a<br>&gt;&gt; linux server via a standard ssh connection on port 22 (using linux
<br>&gt;&gt; username and password), and then communicate with the box-backup<br>&gt;&gt; server via pipes (so no network connections will be involved).<br>&gt;&gt;<br>&gt;&gt; This would help using box-backup on servers that do not allow
<br>&gt;&gt; listening daemons or persistent processes but do allow connecting<br>&gt;&gt; through ssh. The box-backup server maintenance could be executed<br>&gt;&gt; manually through a cronjob.<br>&gt;<br>&gt; You can do this using ssh port forwarding already, although that is
<br>&gt; obviously a bit of work to set up.<br><br>Unfortunately that doesn&#39;t work if daemons are not allowed on the remote<br>host. Although you could start the store daemon when the backup starts and<br>kill it afterwards.
<br><br>Another way might be to mount the remote storage box using sshfs on the<br>client, and run the store and backup daemons on the client.<br><br>Cheers, Chris.<br>--<br>_ ___ __&nbsp;&nbsp;&nbsp;&nbsp; _<br>&nbsp;&nbsp;/ __/ / ,__(_)_&nbsp;&nbsp;| Chris Wilson &lt;0000 at 
<a href="http://qwirx.com">qwirx.com</a>&gt; - Cambs UK |<br>/ (_/ ,\/ _/ /_ \ | Security/C/C++/Java/Perl/SQL/HTML Developer |<br>\ _/_/_/_//_/___/ | We are GNU-free your mind-and your software |<br>_______________________________________________
<br>Boxbackup-dev mailing list<br><a href="mailto:Boxbackup-dev@fluffy.co.uk">Boxbackup-dev@fluffy.co.uk</a><br><a href="http://lists.warhead.org.uk/mailman/listinfo/boxbackup-dev">http://lists.warhead.org.uk/mailman/listinfo/boxbackup-dev
</a><br></blockquote></div><br><br clear="all"><br>-- <br>Thank you.<br><br>Scott McNee<br>Manager<br><br>M : 0415 10 44 10<br>T : 07 3274 3933<br>E : <a href="mailto:scott@bizebox.com.au">scott@bizebox.com.au</a><br> <br>
&quot;backing up your business&quot;<br><a href="http://www.bizebox.com.au">http://www.bizebox.com.au</a><br> <br>DISCLAIMER<br>This transmission is confidential and intended for the addressee only. If you have received it in error, please delete it and notify the sender. Unless explicitly attributed, the opinions expressed in this E-mail are those of the author only and do not represent the official view of bizEbox. bizEbox checks all inbound/outbound e-mail for Viruses. However, we advise that this e-mail and any attached files should be re-scanned to detect viruses. bizEbox accepts no liability for loss or damage (whether caused by negligence or not) resulting from the use of this or any attached files.

------=_Part_68708_2816753.1167175099163--

From boxbackup-dev@fluffy.co.uk  Wed Dec 27 01:03:29 2006
From: boxbackup-dev@fluffy.co.uk (James O'Gorman)
Date: Wed, 27 Dec 2006 01:03:29 +0000
Subject: [Box Backup-dev] Logging framework
In-Reply-To: <Pine.LNX.4.64.0612261840310.29554@rocio.int.aidworld.org>
References: <Pine.LNX.4.62.0612162030380.30917@top.qwarx.com> <20061217102636.GA35329@netinertia.co.uk> <20061224121422.GA35890@netinertia.co.uk> <Pine.LNX.4.64.0612241251040.3591@rocio.int.aidworld.org> <20061224131607.GB35890@netinertia.co.uk> <Pine.LNX.4.64.0612261840310.29554@rocio.int.aidworld.org>
Message-ID: <20061227010329.GA48792@netinertia.co.uk>

On Tue, Dec 26, 2006 at 06:41:43PM +0000, Chris Wilson wrote:
> Last time I checked in, a few days ago, but when the older version was 
> running. Will keep an eye out during the next checkin. How does Trac keep 
> synced with the Subversion repo? Does it rely on a hook, or does it read 
> from the live repo?

As far as I'm aware, it reads the live repo, which is why Trac currently
requires the repo to be on the same system. I don't think there's any
"syncing" involved at all.

James

