Here's a thought. Maybe you're missing some DLL that I'm relying on. Try just running tb-rsync-vss from the command line and see what it says.
Here's what I get: ----------------------------- c:\Program Files\True Blade Systems>tb-rsync-vss-64.exe 0: tb-rsync-vss-64.exe usage: tb-rsync-vss-64.exe volume-to-map map-to-drive command-to-execute [args-to-command] example: tb-rsync-vss-64.exe c:\ x: c:\windows\system32\cmd.exe /t:19 At least 2 parameters required ----------------------------- If you get anything else, it might mean a missing DLL. But this is a pretty vanilla Windows 7 64-bit machine. I don't think I've installed anything like extra VC++ DLLs. Eric. On 3/9/2014 7:50 PM, Gibson McNeil Boyle wrote: > Thanks Eric for the quick response. > Copssh (OpenSSH 6.5p1) and cwRsync (Rsync 3.1.0) are both based on > Cygwin 1.7.27 hence the use of cygwin drive notation is not an issue. > The master.conf file used was the same with and without ssh while the > default.conf file used with ssh (set up successfully for connection > without a password) is as follows: > > client: [email protected] > tree: > "/|tmp-drive=x|rsync=c:/Copssh/ICW/bin/rsync.exe|cygpath=true|c:/Work" > index: text > log: text > expire-default: +15 days > rsync-client: "c:/Program Files/True Blade Systems/tb-rsync-vss-32.exe" > numeric-ids: 1 > > In the case without tb-rsync-vss, the tree string used was > /cygdrive/c/work while the rsync-client entry was commented out > > I am sorry about the use of the word 'convoluted' but I was at a loss of > a better expression to use at the time and I agree with you that in this > instance of a pull transfer of data to the location of the dirvish > routines and the transfer of all parameters in the rsync mode, there > probably is no better option. > > I await your feedback once you have your instances up and running > > Regards > > Gibson > > > On Monday, March 10, 2014 12:01 AM, Eric V. Smith <[email protected]> > wrote: > On 03/09/2014 06:24 PM, Gibson McNeil Boyle wrote: >> I have dirvish setup and tested using both ssh (copssh) and rsync >> (cwRsync). Both utilities are available from www.itefix.no. The setup is >> backing up a windows folder to a NAS (linux platform). Tests copying >> files with and without ssh (rsync daemon) were successful. >> >> To overcome the issues associated with rsync while copying open/locked >> files, I tried out Eric Smith's tb-rsync-vss-32 wrapper. Unfortunately, >> dirvish returned broken pipes errors using ssh. I used a default.conf >> file very similar to the example provided in the Bitbucket article. > > Hmm. There's some way to have tb-rsync-vss-32 produce a log file. > Coincidentally, I'm setting up a new Windows machine so I have occasion > to look into the source code this week. I'll report back on my progress. > >> I shall be grateful to hear about the experience of other users with >> this tb-rsync-vss utility.. >> 1. Is it necessary that I must use cygwin, sshd and rsync instead of >> copssh and cwRsync? > > I don't see why cygwin's versions of these tools would be required. The > code does nothing cygwin specific, that I know of. It does know about > cygwin specific paths, but there's a documented way to turn that off. > It's probably not well tested. > >> 2. If the tb-rsync-vss utility and its convoluted parameters is a >> logical replacement for rsync, should it not be useable in all cases >> where rsync is used including when run as a daemon in a secure network >> possibly with the addition of an extra colon at the beginning of the >> tree string in the default.conf file? > > Heh. "Convoluted" is an understatement. I'm open to ideas on making it > simpler, but if you live with the restriction that all of the > configuration must be done on the side running dirvish and passed via > "rsync" command line parameters, I don't see what other choice you have. > > I don't think it could replace the "rsync as a daemon" scenario, because > it doesn't listen to any sockets. It relies on ssh starting it up, > thinking it's a non-daemon version of rsync. Maybe it could be made to > work with inetd doing the listening, but I've not thought it through > (nor tried it, obviously). > > I hope that helps. When I get my new instance installed, I'll let you > know. I'll be running the 64 bit version, but the source code is > identical between the two versions. > > Eric. > > > _______________________________________________ > Dirvish mailing list > [email protected] <mailto:[email protected]> > http://www.dirvish.org/mailman/listinfo/dirvish > > > > > _______________________________________________ > Dirvish mailing list > [email protected] > http://www.dirvish.org/mailman/listinfo/dirvish > _______________________________________________ Dirvish mailing list [email protected] http://www.dirvish.org/mailman/listinfo/dirvish
