Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

We have to develop our own file management system in Java web application. We need to sync files between our main server and client severs and find out whether all the client server has all the latest version of files.

Our files are in pdf, doc and xls format they changes every now and then as and when it is required.

What we are thinking of using MD5 checksum to find out hashcode of files on Main server and store it in database. Same would be there in Client Servers database. After comparing records on database we would come to know whether client servers are synced or not.

Please suggest if there are any better ways to do the same.

share|improve this question
In short, yes. However, I would suggest a more modern hash, look up SHA on wikipedia. Are you storing the files on disk or in the database? – gahooa Feb 4 '13 at 5:15
@gahooa Files are stored in dosk. Where as file details like filename etc.. are store in database. – codpursue Feb 4 '13 at 6:22
What's wrong with using the modified date of the file? – ThinkingMedia Feb 4 '13 at 8:44
@MathewFoscarini On a file system level, it's fine in many (non-critical) applications, but you could have both false positives (the timestamp getting set directly by a tool) as well as false negatives (e.g. a "touch" command updating the timestamp, but not modifying the file). In the context of the question though, I think you are right, they could just have a "last deployed" timestamp instead of a hash, and use that to compare. – Daniel B Feb 4 '13 at 10:14
Take a look at the design goals (disclaimer: I am author). It would be fairly trivial to port to Java. – gahooa Mar 15 '13 at 8:30

Yes, MD5 is almost guaranteed to detect any change in files you produce. Collision attacks (methods to create different files with identical hash sums) are possible, but that is only a concern when you are fighting an attacker who is actively trying to produce them. In normal operation this is not a concern; your hardware failing is much, much more likely than an accidental collision.

So, mathematically, using MD5 for sync algorithms is fine. But as others have pointed out, there may be ready-made solutions that make more sense for you, or it may be too expensive to scan the full content of every file regularly - that depends on your particular situation..

share|improve this answer
Collisions can also be an issue if someone on your system is just messing around with md5 collisions, and happens to have two files with the same md5sum. My understanding is that there are no known sha1 collisions -- yet. – Keith Thompson Jun 24 '13 at 20:57

About your new wheel design concept - it's been done: rsync

utility software and network protocol for Unix-like systems (with ports to Windows) that synchronizes files and directories from one location to another while minimizing data transfer by using delta encoding when appropriate...

The recipient splits its copy of the file into fixed-size non-overlapping chunks and computes two checksums for each chunk: the MD5 hash, and a weaker 'rolling checksum'... It sends these checksums to the sender...

share|improve this answer
RSync would be the good one if Main Server and our Client Servers are always on network... But in our case we are sending this files from DISK or Email. They are not always on network – codpursue Feb 4 '13 at 6:24
OK, so even if you can't use rsync directly, you can certainly determine how it decides whether two files are in sync. As discussed in some of the comments, it might be enough to check mdate and size, like rsync can do. – David M Feb 5 '13 at 0:41
You have to unpack what you get somewhere, and rsync works just fine between directories on the local system. – Blrfl Feb 5 '13 at 3:04
rsync also solves the non-trivial design of a hashing algorithm that allows you to detect where in the file the change is. – Martin Beckett Feb 5 '13 at 5:14

If you do this, I would recommend comparing the size in bytes prior to the MD5 (or other) hash.

If the size is different between the two machines, you know the file is different. No need to waste time calculating a hash. And for most file types - certainly including those that you mentioned - it is extremely unlikely that a change will leave you with exactly the same file size.

share|improve this answer
Checking the size would be a good idea. Thanks i will do that – codpursue Feb 4 '13 at 12:53

Yes. You know all client files are sync'ed from the server. Therefore, if you keep sufficient history on the server, the client only needs to send its file version. Expensive MD5 calculations are unnecessary.

In the (hypothetical) case that a client can update its copy, you have a much more complicated problem anyway. You cannot support concurrent modifications (not with Excel or PDF) so you would need a checkout-modify-checkin system. At that point you're re-inventing a VCS, so you'd just choose SVN instead.

share|improve this answer
I like this answer because it mentions the two problems I noticed off the bat when reading this question - md5's can be expensive CPU hogs, especially when doing multiples and large files. And, especially considering that it was mentioned that client and server are not always connected, how are you to handle sync of client changes by multiple clients since last check-in? Often times people don't consider a VCS for something that's not code, but it works well. – Drake Clarris Feb 4 '13 at 12:46

It might be easier to just remember when the files were last synced. Calculating a hash for a large file could be expensive. If the modification date is after the sync date on either machine, the file needs to be synced again. Comparing dates is cheap and doesn't depend on file size.

share|improve this answer

MD5 is said to by quite slow (see below). The MD5 digest is rather long. I'd recommend modification time, size and CRC-32 checksum for file comparisons. A discussion on CRC-32 is here. As its name implies, CRC-32 has 32-bit hash values. A Java implementation is available in

Edit: The speed advantage of CRC-32 vs. MD5 is smaller than I've expected. CRC-32 needs some 20% less time compared to MD5.

I used the following Java code to find the difference (and demo the usage of both methods):

import java.util.Random;

public class HashBench {

    public static void main(String[] args) throws Exception {
        int noOfLoopIterations = 100 * 1000;
        int bytesInMessageBuffer = 100 * 1024;

        byte randomByteBuffer[] = new byte[bytesInMessageBuffer];
        byte md5Digest[];
        MessageDigest md5;
        CRC32 crc;
        long crcValue;
        long startTime;     
        long elapsedTime;

        new Random().nextBytes(randomByteBuffer);

        //  MD5 benchmark
        o("Starting MD5 benchmark ...(" + bytesInMessageBuffer/1024 + "KByte messages)");
        md5 = MessageDigest.getInstance("MD5");

        startTime = System.nanoTime();
        for (int i = 1; i < noOfLoopIterations; i++)
            md5Digest = md5.digest(randomByteBuffer);           
        showElapsed(noOfLoopIterations, startTime);

        //  CRC-32 benchmark
        o("Starting CRC-32 benchmark ... (" + bytesInMessageBuffer/1024 + "KByte messages)");
        crc = new CRC32();

        startTime = System.nanoTime();
        for (int i = 1; i < noOfLoopIterations; i++)
            crcValue = crc.getValue();
        showElapsed(noOfLoopIterations, startTime);


    private static void showElapsed(int noOfLoopIterations, long startTime) {
        long elapsedTime;
        elapsedTime = System.nanoTime() - startTime;
        o("Elapsed time:    " + num(elapsedTime / 1000000000.0) + "s for " + String.format("%1$,.0f", 1.0 * noOfLoopIterations) + " loops");
        o("Time per digest: " + num(elapsedTime / (1000000.0 * noOfLoopIterations)) + "ms");

    private static void o(String s) {

    private static String num(double x) {
        return String.format("%1$,.2f", x);


The result:

Starting MD5 benchmark ...(100KByte messages)
Elapsed time:    28,94s for 100.000 loops
Time per digest: 0,29ms

Starting CRC-32 benchmark ... (100KByte messages)
Elapsed time:    23,89s for 100.000 loops
Time per digest: 0,24ms

To avoid the influence of disk caching and other external effects, I just fill a byte array with random values. The benchmark executes the hash/checksum calculation repeatedly.

Conclusion: Calculation speed is not a convincing reason in this case.

share|improve this answer
CRC-32 is a terrible idea here. There are only 4 billion possible values, sooner or later (and not all that much later if you're dealing with enough files) you'll get a collision and suddenly you have a changed file not being updated. The cost of the hash is basically irrelevant anyway as the main cost is the disk IO anyway. – Loren Pechtel Feb 5 '13 at 4:01
Sorry, but I disagree. The combination of size, age and CRC-32 makes it highly unlikely to get a collision. Together, you'd get a "hash" of some 96 bits without the necessity to explicitely store more than 32 bits. Disk I/O is relevant for the elapsed computing time, but MD5 puts more load on the CPU than CRC-32. – Axel Kemper Feb 5 '13 at 8:31
Your disks need to be quite fast for MD5's cost to matter. – CodesInChaos Feb 5 '13 at 15:06
@CodesInChaos: You have a point there, but a.) my disk is a SSD and thus very fast and b.) on a multi-user server, CPU load does matter. – Axel Kemper Feb 5 '13 at 15:23
@AxelKemper: Except you don't get anything like that many bits when you're looking at files which are simply being changed in fairly small ways. – Loren Pechtel Feb 5 '13 at 16:21

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.