Large files (> 2GB) and optimzations for new files

[florisrobbemont]

Added changes to support synchronizing files larger than Int32.Max Added optimization for when a file is new. When there are no chunks in the signature, the file doesn't exist on 'the other side'. It is therefor unnecessary to scan the file twice.

[florisrobbemont]

I know :) that's why the line says ==, and not >. The code will loop untill the bytes read is smaller then the requested buffer size. That moment is the end of the stream.

UPDATE: Scrap that comment... I should learn to read before responding.. You are right! :) I''ll change the code.

[Nisden]

But the buffer is always 1024 * 1024 in size, as you removed the Math.Min method.

So if the stream returns "1024" instead of "1048576" it will think it has reached the end because read == buffer.length would be false. However the stream might return more data, as the stream should return an explicit "0" to indicate that its at the end of its stream.

https://msdn.microsoft.com/en-us/library/system.io.filestream.read%28v=vs.110%29.aspx

zero if the end of the stream is reached.

[PaulStovell]

Hi @florisrobbemont

Thanks for the pull request. They seem like good changes.

In the DeltaBuilder, the changes seem to be quite big and I can't really follow them. If you invert this condition:

if (chunks.Any())
{
    ....lots of existing code that just changed indentation levels

To be:

if (!chunks.Any()) return;
...existing code

That might make the PR much cleaner and then I'll be able to understand if anything else changed.

[PaulStovell]

...and I just realized how old this PR is, I'm sure you've long since moved on by now!

[droyad]

OctoDiff - Large files (> 2GB) and optimzations for new files #5