Free sync software for linux

rsync is a replacement for rcp (and scp) that has many more features. It uses the "rsync algorithm" which provides a very fast method for remote files into sync.

rsync project does this by sending just the differences in the files across the link, without requiring that both sets of files are present at one of the ends of the link beforehand.

Podsyncr allows you to sync photos and sets on Flickr to an iPod. It currently only works with the 2nd generation iPod Nano.

Podsyncr downloads the photos and stores them into an iPod photo database.

Supported Models

Currently only the iPod Nano 2nd gen. is supported. If you have any other model just send me a small sample Photo Database and I will add support for it.

Usage

Start podsyncr.jar
Authenticate yourself to flickr by clicking on auth and following the instructions
click on sync and wait
copy "~/.podsyncr/Photo Database" to the Photos directory on your ipod
copy "~/.podsyncr/F*.ithmb" to the Photos/Thumbs directory

podsyncr is licensed under the GPL version 2 and includes software developed by Aetrion LLC (flickrj).

File::Sync is a Perl access to fsync() and sync() function calls.

SYNOPSIS

use File::Sync qw(fsync sync);
fsync(*FILEHANDLE) or die "fsync: $!";
sync();

use File::Sync qw(fsync);
use IO::File;
$fh = IO::File->new("> /tmp/foo")
or die "new IO::File: $!";
...
fsync($fh) or die "fsync: $!";

The fsync() function takes a Perl file handle as its only argument, and passes its fileno() to the C function fsync(). It returns undef on failure, or true on success.
The fsync_fd() function is used internally by fsync(); it takes a file descriptor as its only argument.

The sync() function is identical to the C function sync().
This module does not export any methods by default, but fsync() is made available as a method of the FileHandle and IO::Handle classes.

SynchroEdit is a browser-based simultaneous multiuser editor, a form of same-time, different-place groupware. SynchroEdit project allows multiple users to edit a single web-based document at the same time, and it continuously synchronizes all changes so that users always have the same version.
SynchroEdits main editor is fully WYSIWYG, dynamically displaying bolds, italics, underlines, strikethroughs, with various justifications, indents and listing styles as an author inputs them. SynchroEdit also supports a simple, text-only editor for more basic documents.
To clarify the multiuser experience, the editor window clearly depicts every users changes in a specific color and also marks where each user is currently editing with a colored flag listing the users name.
SynchroEdit can be used for any functionality where concurrent, synchronous editing of a single document is useful. It can easily be plugged into web pages using a variety of methods. Following are some of the current uses being considered:
Collaborative Editing - Two or more people can edit a document at exactly the same time, fine-tuning specific wordings and phrases.
Teleconferencing Notes - Members of a teleconference can write about their call, correcting or expanding upon notes made by other call members, thus supporting a true backchannel to a live conference call.
Wiki Editing - Editors can edit popular or heavily edited Wiki pages at the same time, instead of having to wait for their colleagues to complete their work.
Pair/XP Programming, Agile Development - Two or more programmers or web developers can write code at the same time.
Teaching Aids - Teachers can provide dynamic syllabi and lecture notes, and students can take shared class notes together.
Documentation Writing - Authors with a variety of expertise can come together to write a coherent document on a specific topic. This overview of SynchroEdit was originally written in SynchroEdit by multiple people.
The SynchroEdit engine consists of three parts:
The Request Server - The initial script that a user connects to in order to initiate a synchronous edit. Current samples are written in PHP and Perl, with a Kwiki Plugin implementation also planned.
The Sync Server - A Java-based server app that talks with the Request Server and Sync Client and mediates the synchronous editing.
The Sync Client - A Javascript archive which is loaded into a users browser. It provides the interface for the actual editing and can support either WYSIWYG or plain editing, as is appropriate for the file type.
SynchroEdit is built around W3Cs Document Object Module (DOM). It ensures that user modifications do not interfere with each other by keeping track of where each user is located in the DOM tree, by node.
User changes to the document are tracked using event-handlers on the DOM mutation events. When data is appended to the DOM tree, unaffected nodes remain as they are, which allows users to safely continue editing, even if other users are modifying large chunks of text elsewhere, and even if there is lag in updates. When user changes are "colliding", the servers ensures the validity of the updated content by comparing out-of-sync updates, and by adjusting the local cursor and node positions.
Besides this solid technical base, SynchroEdit also offers a good user interface to optimize multiuser editing. Each users edits are marked by "author-spanning" and the each users current position is marked with an "author flag". Thus all edits performed by a user are marked in the document in that users specified color, which allows all users to easily see who is making which change.
Enhancements:
- This is the "halfway there" release, which includes a more standardized codebase, administration, and improved interoperability (ESPI and response service).

SyncEvolution project synchronizes Evolutions contact, calender and task items via SyncML. The items are exchanged in the vCard 2.1 or 3.0 format and iCalender 2.0 format via the open source Funambol C++ client API library, which should make SyncEvolution compatible with the majority of SyncML servers (but see under known problems). Full, one-way and incremental synchronization of items are supported.
SyncEvolution does not synchronize with another SyncML capable device or another computer directly. A SyncML server that that device and SyncEvolution can talk to is needed. There are several options for that:
using a web service like ScheduleWorld which stores the data to be synchronized on a ScheduleWorld server and provides access to it via SyncML
installing a SyncML server like the free one from Funambol (www.funambol.com) on ones own server
installing a SyncML server on the desktop
The recommended solution is ScheduleWorld because it is easier than setting up a server and provides better support for vCard and iCalendar data than the stock Funambol server installation. Setting up a server on the desktop has the additional problem that not all mobile devices can communicate with the desktop via HTTP.
With a server that fully supports SyncML and vCard/iCalender the following works:
copy a complete database to the server and restore it from the server later
delete or modify an item locally, then make the same change on the server
delete, modify or add items on the server (by synchronizing with another client), then make the same change locally
conflict resolution (where two clients modify the same item, then sync with the server) is handled by the server, but SyncEvolution has support which ensures that no data is lost by creating duplicates
For conflict resolution and synchronization between clients which support different attributes of items the server needs an understanding of the format of items. The Funambol server supports that for contacts, but not yet for the calendar events and tasks that SyncEvolution sends. ScheduleWorld also works with SyncEvolution and calendars plus tasks.
Enhancements:
- This is the first release with full support for synchronizing of Evolutions contacts, calendars, and task lists.
- It was extensively tested with ScheduleWorld (sync.scheduleworld.com).
- This Web based service is easy to use and a lot of effort went into ensuring that it works well together with SyncEvolution and Evolutions PIM data.

OurNet::BBSApp::Sync is a Perl module to sync between BBS article groups.

SYNOPSIS

my $sync = OurNet::BBSApp::Sync->new({
artgrp => $local->{boards}{board1}{articles},
rartgrp => $remote->{boards}{board2}{articles},
param => {
lseen => 0,
rseen => 0,
remote => bbs.remote.org,
backend => BBSAgent,
board => board2,
lmsgid => ,
msgids => {
articles => [
,
,
],
archives => [
,
,
],
},
},
force_fetch => 0,
force_send => 0,
force_none => 0,
msgidkeep => 128,
recursive => 0,
clobber => 1,
backend => BBSAgent,
logfh => *STDOUT,
callback => sub { },
});

$sync->do_fetch(archives);
$sync->do_send;

OurNet::BBSApp::Sync performs a sophisticated synchronization algorithm on two OurNet::BBS ArticleGroup objects. It operates on the first one (lartgrp)s behalf, updates whats being done in the param field, and attempts to determine the minimally needed transactions to run.

The two methods, do_fetch and do_send could be used independently. Beyond that, note that the interface might change in the future, and currently its only a complement to the ebx toolkit.

FTP SyncAgent is a software that keeps a local folder and a remote FTP folder in sync. All what you need to do is to create a Java properties file (explained here) and start it.

Currently there is only a console-based UI and you will be asked for files to download/upload or remove.

Later on, I will provide a more intelligent agent module which can be pre-configured for common descision patterns and which will be able to choose automatically what to do. Thus, the agent should be able to run as a cron job and periodically check for required updates.

Quick Start

1. Download the latest release of FTP SyncAgent and the two dependent libraries: Jakarta Commons Net and ORO (you will only need the two JAR files commons-net-[version].jar and jakarta-oro-[version].jar).
2. Create a properties (config) file for each directory to sync, e.g. syncedFolder.properties and save it somewhere, lets say in /home/myUser/syncedFolder.properties. The file should contain at least the following lines (you can copy it from here!):

host=ftp.theFTPserver.com
port=21
user=myUserName
pass=myPassword
remoteFolder=absolutePathToTheLocalFolderToSync
localFolder=relativePathToTheRemoteFolderToSync
verbose=true
passive=true
ignore=.backup .bak ~

The host, port, user, and pass properties should be clear, the remoteFolder is the path to the remote folder relative to the FTP home directory (e.g. /mySyncedFiles), the localFolder is the absolute directory path to the local folder to be synced (e.g. /home/myUser/aFolderToSync). The property verbose is just for a more detailed output to the shell when sychronising, passive will enable (or disable) a passive connection to the server (if you are behind a firewall our gateway router), and using ignore you can specify file suffices to exclude.
3. Setup the classpath or specify it when starting (as shown here at the next step). The classpath must contain the two dependent JARs as described under requirements and the FTP SyncAgent JAR file ftpsyncagent.jar.
4. Now you can run FTP SyncAgent with the following command (you must adjust the path to the JAR files according to your directory structure! Create a shell script or batch file for an easier startup):

java -cp /opt/javalibs/ftpsyncagent.jar:/opt/javalibs/commons-net-1.4.1.jar:
/opt/javalibs/jakarta-oro-2.0.8.jar at.langegger.ftpsa.SyncAgent
/home/myUser/syncedFolder.properties

The basic usage is:

java -cp [jar-files] at.langegger.ftpsa.SyncAgent [custom properties-file]

5. Thats all. For any questions, contact me (via e-mail, address below).