Re: [Jfilesync-news] review of JFileSync

[plastic r. <pla...@te...>]

----- Original Message -----
From: "Jens Heidrich" <jhe...@rh...>
To: "plastic rat" <pla...@te...>
Subject: Re: [Jfilesync-news] review of JFileSync
Date: Thu, 13 Oct 2005 18:07:27 +0200

>=20
> Hi Tom:
>=20
> First of all, thanks for your detailed review of JFS :-)
thank you for writing JFileSync :-)
>=20
> plastic rat wrote:
> > You may be interested to know I have written a review of=20
> > JFileSync and a comparison with other file synchronizers, it is=20
> > at=20
> > http://www.tomkelsey.pwp.blueyonder.co.uk/projects/synchronizer_review.=
html,=20
> > please reply with any comments.
>=20
> Here are some comments to some features requested and our plans for the
> future:
>=20
> A) 'token' mode
> Yes, that's an interesting feature and on our my todo list for some time
> ;-). The original plan was to create a kind of patch package you apply
> to a certain file system in order to sync it with another one. The
> package should be created based on an XML representation of the file
> system structure you want to synchronize (like the current
> synchronization history) and contains a set of commands (files to copy
> and delete) and the corresponding files that would have to be modified.
>=20

OK, thats a good idea. If the xml file is stored on the removable disk with=
 the patch, then that is equivalant to 'token mode'.

To get this to match the 'token' mode completely you would need to have JFS=
 detect when a directory had a patch in it and:
 1 apply the patch to the other directory, and then delete the patch
 2 generate a new patch based on the other directory and put this in the xm=
l file directory
 3 update the xml file to match the other dir
ideally this would all happen automatically when you tried to 'sync' a dire=
ctory that contained a patch

> May be, I have some time to work on it for 2.2, but it's unlikely,
> because current effort is more focused on JFS usability issues.
>=20
> B) client-server compressed protocol
> C) client-server encrypted protocol
> Yes, JFS has a built-in server that doesn't support compression nor
> encryption. The usage scenario is to use this server as part of an SSH
> tunnel (which usually is able to support this kind of stuff). I'm
> thinking of directly supporting connections to an SFTP server, but this
> would limit server client connections to Unix (and Cygwin-based)
> systems. It should also be easier to use the server from the GUI in the
> future. For encrypten we would have to use SSLSockets, which would
> perfectly be possible, but nobody demanded it so far ;-).
You're right encryption should probably not be done in a syncing program.
Compression may be more valuable. Unison and rsync both claim they only sen=
d the parts of files that have changed. I guess they must do this by partio=
ning the file and checksumming each part. This would use less bandwidth tha=
n running it through a compressed link.

>=20
> D) >2 machines
> JFS stores a history for each file pair; so a source directory can be
> synchronized with multiple target directories (or vice versa ;-).
> However, if you connect an external drive that uses drive letters (e.g.,
> "D:") you will have problems because the file pairs look the same even
> if different external drives will be connected to your system
> subsequently (always e.g., src=3D"c:\MyData", tgt=3D"d:\MyData"). If you
> access multiple network drives, for instance, there should be no problem
> with mixing up histories (e.g., pair 1: src=3D"c:\MyData",
> tgt=3D"\\test1\MyData" and pair 2: src=3D"c:\MyData", tgt=3D"\\test2\MyDa=
ta").
>=20
ok. i didn't know this, I will update the review.
The situation of different removable drives could be detected maybe by stor=
ing a GUID in each directory that is synced, and a copy of it in the synchr=
onisation history?

> E) select single files
> Yes, only directories can be part of sync profiles.
>=20
> F) use non RW media
> Yes, it is only supported by the underlying system drivers (if your OS
> is able to integrate the CD-R as a standard drive that can be accessed
> like any other folder).
>=20
I put in this criteria because I had a problem with this before got I got a=
 usb drive.
Namely one of the machines I was working on could not read packet formatted=
 cds, but all the syncing progs available needed to write directly to the d=
irectory.
so I had to:
write one directory onto the cd
move the cd to other machine
do a merge on all files
write the directory on this machine onto cd
repeat on other machine

This could be solved by your patch feature.
Basically you could use JFS to generate a patch based on an xml file on the=
 cd, then write the patch & new xml file to a new session on the cd.

> G) dummy mode
> JFS only supports a "test mode" (via Profile Manager -> Advanced), it
> will only simulate a synchronization, but it will, however, not output
> the files that have to be copied and deleted, but you may view these
> files anyway by pressing "Show Details" before starting a synchronization.
>=20
I was thinking of getting an output on the command line so you could implem=
ent features like creating patches in a separate script
>=20
> Thanks again for your review and for evaluating JFileSync :-).
>=20
no problem.
thanks again for writing JFileSync

>=20
> Cheers,
>=20
> Jens.


bye,

Tom


--=20
___________________________________________________
Play 100s of games for FREE! http://games.mail.com/