In that case, there are two strategies for synchronizing file systems -- either:
1. The operator tells the program what to do.
-- or --
2. The program gets it wrong at least some of the time.
In the case of contact list synchronization, like Google Contacts, the system assumes that the device the operator is editing at the moment is the source, and acts accordingly. Notice that a positive determination is made as to what the source and destination are, based on the operator's activity and its timing.
In all other cases where two directory trees are synchronized, are made to have the same content, and in which files may be deleted as well as added, the operator has to tell the program which is the source and which is the destination. End, full stop.
I agree that you need some user input or the program will get it wrong in some cases.
But the distinction between source and destination is relevant with some algorithms (one-way sync) and irrelevant in others.
Let say you have two directories A and B to sync and both contain a file f but the one in B is more recent than the one i A. A consistent strategy would be to always favor the most recent file and end up with A and B containing the same f file that was the one being in B at the beginning of the syncing. At no point I asked the user to define a source nor a destination but still the two directories are synced.
Note that it is your choice to continue or not the discussion as much as it was mine (not yours, shockingly) to answer your post.
So please keep your "End, full stop" and "Think before answering" to yourself, they are quiet annoying.
> But the distinction between source and destination is relevant with some algorithms (one-way sync) and irrelevant in others.
True, but the decisions made by the operator are critical to any desirable outcome, in all cases, without exception. Your example proves the point:
> Let say you have two directories A and B to sync and both contain a file f but the one in B is more recent than the one i A. A consistent strategy would be to always favor the most recent file and end up with A and B containing the same f file that was the one being in B at the beginning of the syncing.
Yes, unless that's not what the operator wants. Suppose the operator has edited a file as part of a programming project, but introduces a bug and simply wants to restore the system's original state with a minimum number of file operations. In that case, the operator wants older dated files to be copied over newer ones.
How shall the algorithm proceed? The operator tells it what to do.
> So please keep your "End, full stop" and "Think before answering" to yourself, they are quiet annoying.
If people understood the meaning of file synchronization, I wouldn't have to. All the replies suffer from naive assumptions contradicted by real-life experience, such as the OP losing his music collection as just one example, or the example I just gave -- things that happen to real people in the real world.
1. The operator tells the program what to do.
-- or --
2. The program gets it wrong at least some of the time.
In the case of contact list synchronization, like Google Contacts, the system assumes that the device the operator is editing at the moment is the source, and acts accordingly. Notice that a positive determination is made as to what the source and destination are, based on the operator's activity and its timing.
In all other cases where two directory trees are synchronized, are made to have the same content, and in which files may be deleted as well as added, the operator has to tell the program which is the source and which is the destination. End, full stop.