bytesRemaining = fileSize;
    while(...) {
        ...
        bytesRemaining -= 8192;
        if(bytesRemaining < 0)
            break;
        ...
    }
    bytesRemaining += 8192;
    ...
    // process remaining bytes

So not simply 8kb as the (current) title states.

P(filesize is multiple of 8192 | crashed) = P(crashed | filesize is multiple of 8192) * P(filesize is multiple of 8192)/P(crashed)

Where:

- The likelihood of crashing given the filesize is a multiple of 8192 is 1;

- The naïve prior of the filesize being a multiple of 8192 is 1/8192;

The task is now to estimate the probability P(crashed), which is the probability the program will crash for whatever reason.

Sometimes you will get zero bytes read return values. Like when there really isn't a byte more to read. So zero bytes available doesn't signal an error.

Another reminder to always test the edge cases (as though we needed another :) ).

If you want to sell your product as closed source, IMO you should put something into place to detect corruption, or at least diagnose how it occurs.

Even worse is that this whole article is about workarounds... Unless I'm mistaken, these seem to be known issues - will Adobe be making fixes? I'm fairly certain that an 8kb bug should be fixed pretty easily.

http://www.adobe.com/uk/products/dreamweaver/features.html

It's interesting as a classic example of an off-by-one bug, one that happens in seemingly strange conditions (8K multiples), and one that affected a major product from a big company.