Use LastWriteTimeUtc when files have the exact same length

[manu-st]

This is to better see if files are different or not while waiting
for the MD5 implementation. This is not bullet proof but better than
what exists today.

This is to address issue #33

[x2764tech]

@manu-silicon FileInfo.LastWriteTimeUtc doesn't seem to be supported on Windows Phone or Silverlight

[manu-st]

There is LastWriteTime which would work for those platforms. Since this is just trying to copy files that have been changed while keeping the same size, it might still work better than not copying them at all. In any case the proposed PR is not a full solution. I would actually rather always copy the files rather than trying to be smart as this is very hard to fix from the client side.

[x2764tech]

Maybe a better way would be allow passing a Func<SftpFile, FileInfo, bool> (or create a delegate with a similar signature) to let you override comparison? This way, people can implement their own strategies

[jenshenneberg]

Some sftp servers, for instance DoveTail Co:Z SFTP (On z/OS mainframe), does not support MD5, gives only an approximate file length and gives a timestamp that is NOT equal to LastWriteTime(It is the last access time instead). The reasons for this are, as far as I know, technical limitations on z/OS.

So in that scenario the only sensible file comparison during synchronization is on filename, unfortunately.

For that reason I would suggest either the delegate of func as x2764tech suggested, or a SyncOption class/enum to specify behavior.

[x2764tech]

@jenshenneberg maybe we could build in some default delegates:

public static class SyncOptions
{
    public static bool Default(SftpFile remoteFile, FileInfo localFile) 
    {  
        return localFile.Length != temp.Length;
    }
}

These could then be used like an enum:

client.SynchronizeDirectories("/", @"C:\temp\", "*.*", SyncOptions.Default);