* If a 416 is returned and we used a Range header, try again
from scratch.
* The direct URL logic was also inconsistent for resumed downloads:
it sent the Range header but didn't check the returned
Content-Range header correctly. Now resuming is disabled for
direct URL downloads.
If lastEtag was null, a force sync was triggered. Force syncs
don't update the etag. The etag retrieval job would only run if
lastEtag was not null. So it could never become non-null.
Use the right check to determine whether a file has a blacklist entry,
SyncFileItem::FileIgnored was incorrect because that denotes files from
the ignore list or blacklisted files with no retries left.
The blacklistedInDb flag does the right thing. Rename it to
hasBlacklistEntry to be more explicit.
The server keeps the mtime and etag anyway.
And changing the mtime also changes the etag and so make other clients re-download
the file instead of detecting the move
By enabling ARC for GCDAsyncSocket (as we should have done before
https://github.com/robbiehanson/CocoaAsyncSocket/wiki/ARC) there
is no chance anymore for a situation where the to-be-written NSData*
is deleted before the socket has had a chance to write it.
Interestingly, this only happened after switching to local sockets,
probably because of how immediatly the NSData* would be sent.
This commit also keeps the debug symbols for the Finder plugin.
The server keeps the mtime and etag anyway.
And changing the mtime also changes the etag and so make other clients re-download
the file instead of detecting the move
The SocketAPI sends status updates for files without being asked for.
And in order to not draw the emblem again if it had not changed, the
state is compared before calling add_emblem
