An empty file is a legal file type on MacOS and iOS. The fact that there is a kind of legal file which, when present, prevents sync from working seems to me indistinguishable from a bug. Are there other instances of legal files that stop sync from working? That also seems like a security risk - if somebody can share a file the contents of which interfere with how sync works, that’s a scary attack vector.
Whether it is a code bug or a design bug is a different question.
The sync intentionally stops to prevent possible damage to files in certain circumstances:
The point that the OS allows zero-byte files isn’t the issue. The issue is there can be zero-byte files that are problematic in a database, hence the sync is inhibited to avoid passing along any inconsistencies.
As I said, we are considering some modifications to allow for certain use cases.
Is it fair to say there was a bug in DT which led to data loss (specifically by setting files in certain circumstances to zero-length and then replicating those modifications), and that the fix was to disallow replication of zero-length files? And that this has the side-effect that DT doesn’t work correctly for people whose databases contain legitimate zero-length files?
If that’s an accurate summary of the situation, I would have preferred more robust communication about the issue from the start – aren’t we now in the situation where we may have lost data and we may not be aware of it, and we may even have gone and deleted the zero-length files without first taking the time to understand what data may have been lost?
Maybe you can remind us what date this bug showed up so we can explore the possibility of needing to restore from backup.
Is there a way to “diff” between two versions of a database?