Cloud-based Synchronization of

Distributed File System Hierarchies

Sandesh Uppoor∗ , Michail D. Flouris∗ , and Angelos Bilas∗†
∗
Foundation for Research and Technology - Hellas (FORTH)
Institute of Computer Science (ICS)
100 N. Plastira Av., Vassilika Vouton, Heraklion, GR-70013, Greece
† Department of Computer Science, University of Crete

P.O. Box 2208, Heraklion, GR 71409, Greece

{suppoor, flouris, bilas}@ics.forth.gr

Abstract—As the number of user-managed devices continues
to increase, the need for synchronizing multiple file hierarchies
distributed over devices with ad hoc connectivity, is becoming a
significant problem. In this paper, we propose a new approach
for efficient cloud-based synchronization of an arbitrary number
of distributed file system hierarchies. Our approach maintains
both the advantages of peer-to-peer synchronization with the
cloud-based approach that stores a master replica online. In
contrast, we do not assume storage of any user’s data in the
cloud, so we address the related capacity, cost, security, and
privacy limitations. Finally, the proposed system performs data
synchronization in a peer-to-peer manner, eliminating cost and
bandwidth concerns that arise in the ”cloud master-replica”
approach.
Index Terms—File synchronization, data management, dis-
tributed storage, cloud service.
I. I NTRODUCTION
Users increasingly depend on electronic information that is
processed and stored in a multitude of computers and storage
devices, connected by both wired and wireless networks. The
number and type of devices, has increased recently due to
the significant growth of affordable smart devices, as well
as the quality and cost of the networking infrastructure. The
increased number of devices and locations and the fact that
many of these devices have limited storage capacities and
exhibit ad hoc network connectivity, such as frequent off-
line operation and/or movement through different networks,
introduce many challenges in managing user data distributed
over multiple devices and many locations.
One of the challenges in maintaining distributed user data is
synchronizing replicated data sets between an arbitrary number
of nodes. This is useful not only for backup purposes, but also
for off-line operation, where a user with a device of limited
capacity needs to selectively replicate part of a data set, modify
it off-line and then re-synchronize with the main data set when
networking conditions allow it.
Currently there are two main approaches to the distributed
synchronization issue, the user-controlled peer-to-peer syn-
chronization and the cloud master-replica synchronization
approach. In the first approach users install synchronization
978-1-4244-8396-9/10/$26.00 
c 2010 IEEE
software, such as rsync [1], Unison [2] or Sync Butler [3]
in all computers containing the data files and explicitly ini-
tiate a peer-to-peer synchronization whenever they need to
synchronize their files. This is a ”manual” process requiring
the user to provide the network addresses of all device(s),
as well as the synchronization parameters, such as direction
of the synchronization, which files to keep or overwrite,
etc. Furthermore, most of these synchronization applications
operate pair-wise, that is they synchronize only a pair of
nodes each time. Managing synchronization for three or more
file system hierarchies can be a cumbersome and error-prone
process, especially for the average user without technical
skills [2]. Finally, the synchronization software is usually not
portable across operating systems, not automated (requires
user intervention), and not suitable for small mobile devices
with ad hoc connectivity.
The second approach, cloud master-replica synchronization
solves some of these issues by employing cloud services
to automate synchronization and deal with the small mobile
devices with ad hoc connectivity. In the approach followed
by many cloud-based synchronization and backup services
(e.g. [4], [5], [6], [7]), a master replica with all data to be
synchronized is maintained as a central copy in the cloud,
while all the user’s file systems synchronize and transfer
updates to this central copy. This approach with one-way
synchronization to the master replica in the cloud, offers in-
creased availability and reliability in case of device failure(s),
automates synchronization management and does not require
technical skills. On the other hand, it makes the assumption
that all user’s data will be stored online in the cloud. This is
not only expensive, because cloud storage capacity costs, but
also introduces important security and privacy concerns. Fur-
thermore, it requires significant (upload) bandwidth between
all replicas and the central copy in the cloud, which may be
limited and/or expensive, while local, peer-to-peer connectivity
between some of the replicas is cheap and high-speed (e.g. a
laptop and a mobile phone synchronizing over a home LAN
with limited upload bandwidth to the Internet).
Note that the approaches mentioned above operate at the
user level, and not in the operating system, as file systems do.

INTERNET
Fig. 1. Cloud service and user devices.
Unfortunately, file systems that support replication and offline
operation mandate the use of the specific file system, which
is often not an option for users.
In this paper, we propose a new approach for efficient cloud-
based synchronization of distributed file system hierarchies,
dealing with an arbitrary number of synchronization nodes.
Our approach maintains both the advantages of peer-to-peer
synchronization and the cloud-based master-replica approach.
It does not assume storage of any file data in the cloud, so it
addresses the capacity, cost, security, and privacy issues. More-
over, the proposed solution performs data synchronization in a
peer-to-peer manner, eliminating cost and bandwidth concerns
that arise in the ”cloud master-replica” approach. Our main
contribution is the design of new algorithms and protocols
that are more complex than the afforementioned approaches,
but provide more benefits and less drawbacks.
This paper presents the design of our system, Synchronizer.
Since a system prototype is currently under development, we
do not present implementation details, or evaluation results.
The rest of this paper is organized as follows. Section II
discusses the design of Synchronizer and how it addresses the
associated challenges. Finally, we draw our conclusions and
discuss future work in Section III.
II. S YSTEM D ESIGN
In our approach we assume a scenario where a user needs
to synchronize a number of data files stored in the file systems
of multiple devices (or nodes), each located in a different
location with ad hoc connectivity. In the rest of this section,
we consider the terms ”device” and ”replica” as synonymous.
Also we denote the hierarchy of directories with many data
files and sub-directories in a single file system as a filetree. For
simplicity we will assume that a device (or replica) contains
a single filetree to be synchronized.
1) Assumptions: Our synchronization scheme requires the
use of metadata for every file in all devices. Metadata consists
of file and directory information, i.e. file system metadata, as
well as a cryptographic hash (e.g. SHA256) of a file’s data
content. The hash is used to compare data across files, and
to detect data modifications of a particular file in a filetree.
Given a file f , its metadata is defined as
M (f ) = { path (directory), name, size, creation time,
last modification time, data hash}
Besides the devices storing the filetrees, we assume a
cloud service, i.e. a node in the Internet cloud that provides
the synchronization services, as shown in Figure 1. This is
necessary in order to automate synchronization, scale up to
any number of devices, and address the issues of devices with
ad hoc connectivity. We also assume that the cloud service is
able to connect and communicate with the devices over the
Internet, when they are able to connect, and collect metadata
of the filetrees from each device. Each device may periodically
send updates for its filetree(s) to the cloud service, however,
we do not make an assumption on the update model (push or
pull), as long as the filetree metadata on the cloud service are
updated frequently.
2) Initial synchronization: Before the initial step of our
system we assume that the user has configured the cloud
service with information on how to connect to the devices
and which filetrees need to be synchronized. This can be done
through a user-friendly user interface, such as a web interface.
In order to retrieve the current filetree state, the cloud
service connects to the devices and gets the updated metadata.
Then, it calculates the file operations which need to be
performed across replicas. First time, when a synchronization
process is performed between filetrees of different nodes, there
is no previous state stored in the cloud service, in contrast to
the subsequent synchronization operations. In this initial step,
we create the synchronization state by performing the basic
synchronization algorithm between two filetrees, as detailed
in the First Sync Algorithm (II-2). File operations in the
algorithm, e.g. delete, rename, copy, are considered atomic.
The copy operation used in the Algorithm II-2 refers to the
transfer of a file from one replica to another. It can be either
full file transfer when it is encountered as new, or transfer
of just the modification when its encountered as modified.
Rename refers to changing in name of an existing file, or
moving it across directories within the same device.
After the cloud service computes the operations for all
files on all filetrees, it sends them to the replicas to be
performed through the coordinated peer-to-peer networking
protocol discussed in II-5.
3) Stateful synchronization: Once the initial operations sent
by the cloud service have been executed on the replicas
successfully, they are known to be in a synchronized state
(or simply “sync state”), where all replicas have the same
copy of data or filetree. This “sync state” of each replica
computed by the initial synchronization is stored in the cloud
service. Note that this state consists only filetree metadata,
not data. Whenever a subsequent synchronization needs to be
performed, the “diff sync state”, i.e. the changes to the filetree
since the previous sync, can be obtained as a difference of the
stored previous sync state and current filetree state read from
the replica.
For a replica A,
PA = previous sync state of A
CA = current state of A
DA = diff state of A
DA = CA - PA
The diff states of replicas are carefully analyzed to detect
individual changes to files. A “file change” refers to either
a file content modification, a file rename, a file creation or
Algorithm 1 First Sync for two filetrees. Algorithm 2 File classification.
Let F TA and F TB be two filetrees, on nodes A and B Let PA ,PB ,PC be the previous sync states, and CA ,CB ,CC
respectively. d refers to a directory name (absolute path from the current states of replicas A, B and C respectively.
root of FT), f to a file name (within a directory), and hash(f ) Let DA ,DB ,DC be the diff states between the previous sync
to the hash of a file’s data. state and current state of each replica.
Modified Renamed
for d in F TA do Let DA be the set of Modified files, DA the set of
New Delete
if d exists in F TB , such that d == d then Renamed files, DA the set of New files, and DA the set
for f in d do of Deleted files in replica A after a previous sync.
if f  does not exist in d , such that f  == f then
f is a new file to be copied to d for node X in A, B, C do
else if f  exists in d , such that f  == f then for file f in CX and f  in PX , such that f  == f do
if hash(f ) != hash(f  ) then if hash(fCX ) != hash(fP X ) and
file f exist but is modified name(fCX ) == name(fP X ) then
if fT imestamp > fT imestamp then f is classified as Modified → DX Modified

copy modification to f  else if name(fCX ) != name(fP X ) and

else hash(fCX ) == hash(fP X ) then
copy modification to f f is classified as Renamed → DX Renamed

end if else if f is not in PX then

else if hash(f ) == hash(f  ) then f is classified as New → DX New

same file f exist unmodified else if f  is not in CX then

end if f is classified as Deleted → DX Delete

else if f  exists in d , such that hash(f  ) == else

hash(f ) then f is unmodified
file f exists in F TB with same content but differ- end if
ent name end for
if fT imestamp > fTimestamp then end for
rename f  to name(f )
else
rename f to name(f  ) two replicas may contain changes in different parts of it that
end if need to be merged using a word processing application). Most
end if existing synchronization applications or cloud services require
end for user intervention for resolving conflicts, or just keep all file
else versions with different file names [2], [4].
create d in F TB and copy all files in d to F TB
end if State of F TX /F TY Mod Ren Del
Modified Mod-Mod Mod-Ren Mod-Del
end for Renamed Ren-Mod Ren-Ren Ren-Del
Deleted Del-Mod Del-Ren —
TABLE I
C ONFLICT TYPES .
a file deletion, with respect to its previous sync state. In a
diff state of a replica, the diff state of each file can be in
one of five different types: modified, renamed, deleted, new Conflicts can be categorized in four types, as shown in
or unmodified. The detection of file changes in a replica and Table I. The diff state of any two replicas is shown in each
the computation of diff state is described in Algorithm II-3: dimension in Table I, while the conflict category depends on
File classification. the independent changes made to a file in each replica.
4) Conflict detection and handling: When a file is modified Our algorithm is able to detect all conflicts, however, due
in one or more replicas, we need to find the latest version of to lack of space we only present part of it in Algorithm 3,
the file and propagate it to the other replicas. The case of a that detects a Mod-Mod conflict. A conflict of type Mod-Mod
file being independently modified in more than one replicas, refers to modifications done to a file f independently in two
is considered a conflict between file versions. Detecting the or more replicas.
correct version of the file in the case of conflicts is difficult and Conflict resolution is an important component in every
dangerous. An incorrect decision in the case of a conflict will synchronization system. Our approach offers two alternatives,
result in data loss, since the correct file version is overwritten ”Manual” or ”Auto” mode. Manual mode requires user input
with another. In many cases, resolving the ambiguity of a in selecting which file(s) to keep, whereas Auto mode provides
conflict requires user intervention and merging of files at the the option of setting up some conflict resolution policies.
application level (e.g. a document independently modified in The current options for policies are: (i) Keep the most recent
Algorithm 3 Mod-Mod conflict detection.
Modified
for f in DA do
Modified Modified
if f in DB or f in DC then
f is in Mod-Mod Conflict
end if
end for
Replica A Replica B
Replica D Replica C
Fig. 2. Peer-to-peer replica synchronization.
version depending on timestamps, (ii) Keep all conflicted file
versions with different names. Once all conflicts are resolved,
either via manual or auto mode, the cloud service starts
computing the operations to be performed by the replicas.
5) Update propagation: Before discussing processing of
conflict-free sync state, it is important to discuss the planned
propagation of file operations to the replicas. The user is likely
to have updated files in many replicas, so the source of file
updates is usually not a single replica, but several replicas.
In this case, communication may become complex, because
it involves transferring files between all replicas. An example
with 4 replicas is shown in Figure 2, where updates from each
replica should be propagated to all other replicas. This requires
all-to-all communication, which is impractical with firewalls
between replicas, and increases protocol complexity to handle
ad hoc communication between replicas (i.e. failures).
Instead of all-to-all communication, we consider an ap-
proach where one replica acts as the master or coordinator.
Thus when calculating the update operations between all repli-
cas, we consider one replica as the master and batch all update
operations to phases, where each phase batching operations
between the master and one other replica. Due to lack of
space we omit details of processing the diff state of filetrees
and performing optimizations to save network bandwidth, for
example in the case of renamed files or directories. We only
describe a summary of the process using phases between the
coordinator and the rest of the replicas.
All operation phases are computed in the cloud service
and then sent to the master replica for performing peer-to-
peer synchronization between all replicas. To propagate all the
updates and to attain a complete sync state with each replica,
we need two rounds of communication with the master replica.
An example of the first round is shown in Figure 3. As
shown, when phase 1 is executed between the master replica
A and replica B, all updates from B are propagated to A hence
at the end, replica A contains updates of A+B. Similarly, after
phase 2 is executed with master replica, all A+B updates from
master is propagated to C and updates from C is propagated
to master, which at the end will contain updates A+B+C.
After the master replica executes the first round of phases
Cloud Service
Replica A (Master)
Phases 1,4 2,5 3,6
Replica B Replica C Replica D
Fig. 3. Synchronization with a master replica.
with all replicas i,e. phases 1, 2 and 3, during which, all
replicas propagate the latest version of updates to the master
replica, the master will contain the latest versions of all files
and directories in all replicas. During the second round of
phases, i.e. phases 4, 5 and 6, the latest versions of files
and directories from the master replica are propagated to the
rest. So, for example, when the master replica containing
A+B+C+D executes phase 4, all updates from C and D are
propagated to B, but there is no updates from B to master
replica since it has already been propagated in first round in
phase 1. In case any replica is unreachable or fails during the
propagation of updates, the process is aborted and operations
are recalculated in the cloud service without the faulty replica.
This is necessary to avoid overwriting a newer file version with
an older file, and is orthogonal to the communication scheme
used (coordinated or all-to-all file update protocol).
III. C ONCLUSIONS
In this paper, we propose a new approach for efficient cloud-
based synchronization of an arbitrary number of distributed
file system hierarchies. Our approach maintains both the
advantages of peer-to-peer synchronization with the cloud-
based approach that stores a master replica online. In con-
trast, we do not assume storage of any user’s data in the
cloud, so we address the related capacity, cost, security and
privacy limitations. Finally, the proposed system performs
data synchronization in a peer-to-peer manner, eliminating
cost and bandwidth concerns that arise in the ”cloud master-
copy” approach. Since a system prototype is currently under
development, we do not present implementation details, or
evaluation results.
ACKNOWLEDGMENTS
We thankfully acknowledge the support of the European
Commission under the 7th Framework Programs through the
FP7 ITN project SCALUS (contract no 238808).
R EFERENCES
[1] A. Tridgell, “Efficient algorithms for sorting and synchronization,” 2000.
[2] B. C. Pierce, J. Vouillon, and J. Vouillon, “What’s in unison? a formal
specification and reference implementation of a file synchronizer,” tech.
rep., 2004.
[3] “Sync Butler.” http://code.google.com/p/syncbutler.
[4] Drew Houston and Arash Ferdowsi, “Dropbox.” www.dropbox.com.
[5] CodeDroids, “OneSync.” http://onesync.googlecode.com.
[6] Siber Systems Inc., “GoodSync.” http://www.goodsync.com/support/manual.
[7] L. Yecies and D. Mihovilovic, “SugarSync.” https://www.sugarsync.com/.