Make sure when nebs receives a FILE_DELETE that it checks it's local mtime
If the delete comes in after it's own tracked mtime, then it had an update newer than the delete. It should discard the delete.
However, when it sees this, it now knows that whoever sent it that message is out of sync. Their file got deleted. The correct state is to have the file (and children). It should probably reply back and say the tree needs to be updated.
Maybe just in general when a mirror tries to send updates it should be told if it's good (newer) or not (bad). If it's trying to send good updates, they are accepted. If they are bad, then the recipient replies back with the path that should be refreshed.
Though what if A sends a file update to B, which has a newer delete? How is that even possible? It probably is. The first few paragraphs describe using the file's mtime to decide which update is newer, but this requires which connection/action is newer. In this case, B wouldn't even remember its delete.
Make sure when nebs receives a FILE_DELETE that it checks it's local mtime
If the delete comes in after it's own tracked mtime, then it had an update newer than the delete. It should discard the delete.
However, when it sees this, it now knows that whoever sent it that message is out of sync. Their file got deleted. The correct state is to have the file (and children). It should probably reply back and say the tree needs to be updated.
Maybe just in general when a mirror tries to send updates it should be told if it's good (newer) or not (bad). If it's trying to send good updates, they are accepted. If they are bad, then the recipient replies back with the path that should be refreshed.
Though what if A sends a file update to B, which has a newer delete? How is that even possible? It probably is. The first few paragraphs describe using the file's mtime to decide which update is newer, but this requires which connection/action is newer. In this case, B wouldn't even remember its delete.