Hacker News Reader

Comment by lutusp | Hacker News Reader

> Rsync does work this way ...

Indeed it does, and that is the true meaning of sync. Consider this example:

$ rsync -a --delete (A) (B)

If (A) is empty, watch (B) become empty too. The point I'm making is that the use of the "--delete" option causes rsync to agree with the true technical meaning of "sync". Without it, the two directory trees (A) and (B) cannot be guaranteed identical at the end of the process (the real meaning of sync).

> ... and that doesn't - to my knowledge - imply any directionality in it ...

Of course it does. How else can you make two directory trees identical if your intention is to delete some files from both trees?

> and dictionary definition [1] seems to agree.

Never rely on a dictionary in a technical discussion. Contrary to popular belief, dictionaries do not list word definitions, they list what people think words mean. This is why "literally" and "figuratively" are listed as synonyms.

View on HN

> Contrary to popular belief, dictionaries do not list word definitions, they list what people think words mean.

I have no idea what you think the definition of a word is, besides what people think it means. Are you imagining a platonic Word floating in the ether somewhere that we see in a mirror, dimly? Is there some official "This Is What Words Mean" tome somewhere that all true definitions flow from? Was there some secret international treaty wherein all word definitions were all agreed upon?

> I have no idea what you think the definition of a word is, besides what people think it means.

Really? There are any number of words whose proper meanings and contradicted by what people think they mean. Examples abound, here's just one:

Literally:

http://www.merriam-webster.com/dictionary/literally

1 : in a literal sense or manner : actually <took the remark literally> <was literally insane>

2 : in effect : virtually <will literally turn the world upside down to combat cruelty or injustice — Norman Cousins>

This is what people think "literally" means. But it is not what "literally" actually means. The common perception is false.

> Is there some official "This Is What Words Mean" tome somewhere that all true definitions flow from?

1. Only for certain terms. There are plenty of examples.

2. On the topic of words, you need to learn the meaning of deconstructive postmodernism, the fascinating idea that there are no shared ideas, that everything is a matter of opinion.

> Was there some secret international treaty wherein all word definitions were all agreed upon?

Classic straw man.

> This is what people think "literally" means. But it is not what "literally" actually means. The common perception is false.

Whence did the "correct" definition of "literally" arise, and how does this origin differ from that of the "incorrect" definition?

You missed my point, which is that, no matter which definition one chooses, a word cannot simultaneously mean what people think it means, and the opposite of what people think it means, at the same time. Even given the fluid nature of word definitions, that's not rational. That's why I choose this example over and over again, not because of what "literally" means, but because it cannot possibly mean A and not-A at the same time.

And some words have technical meanings that are contradicted by popular usage, like "theory" in science. Many people think "theory" means "hunch" -- "but it's just a theory, you know?" In science, theory has a specific meaning contradicted by the everyday understanding.

In the present case, file synchronization has a specific meaning that many people don't know. This misunderstanding causes them to lose their music collections.

Of course they can. Words have contradictory definitions.

There's even a name for them: contronyms.

> it cannot possibly mean A and not-A at the same time.

Here's an old joke:

    A linguistics professor was lecturing to his English class one day. 'In English,' 
    he said, 'A double negative forms a positive. In some languages, though, such as
    Russian, a double negative is still a negative. However, there is no language
    wherein a double positive can form a negative.'

    A voice from the back of the room piped up, 'Yeah, right.'

> no matter which definition one chooses, a word cannot simultaneously mean what people think it means, and the opposite of what people think it means, at the same time.

A word can have multiple meanings, and those meanings can be related, or unrelated, or contradictory, or anything in between. When a person uses a word, usually they intend one of those meanings, but you can also intend multiple meanings at the same time—thus double entendres. You can also say something, but mean something different, or even the opposite—thus irony and sarcasm.

> And some words have technical meanings that are contradicted by popular usage, like "theory" in science. Many people think "theory" means "hunch" -- "but it's just a theory, you know?" In science, theory has a specific meaning contradicted by the everyday understanding.

"Theory" has multiple meanings, some of which people are unfamiliar with. But their understanding isn't wrong, they just don't know the meaning that the speaker intends.

> synchronization has a specific meaning that many people don't know.

Synchronization has multiple meanings—thus why we have post after post arguing about which is correct.

> This misunderstanding causes them to lose their music collections.

This, I agree with you about.

If you think about the parent's case, unidirectional syncing ended up causing empty dataset to be synced from the computer to the iPhone. That doesn't seem right. Compare this to Dropbox's model of syncing: intentional changes (yes, deletes as well) are synchronized and this is done multidirectionally between all the participating devices. This is what seems to me like a better definition of sync.

Or consider your mobile device calendar. You add an appointment on your phone, it doesn't disappear when you sync with your PC (or with cloud, as is common today).

I didn't mean to imply that dictionary defines the meaning, but it does seem to agree with what I mean with "sync". Where does this "true technical meaning of sync" come from?

> If you think about the parent's case, unidirectional syncing ended up causing empty dataset to be synced from the computer to the iPhone.

Not if the user selected the new iPhone as the source. In fact, that's the only way the described outcome could happen -- assuming the desktop machine originally had a full collection of music and the iPhone was empty.

> That doesn't seem right.

True, it doesn't seem right. But the customer is always right.

> Or consider your mobile device calendar. You add an appointment on your phone, it doesn't disappear when you sync with your PC (or with cloud, as is common today).

A perfect example. What if your phone is the source of most of your appointments and contacts? Wouldn't it seem logical to make the phone the source for a sync transaction?

Let's take the next step -- what if your phone is the source of your music collection? What if you add music to your phone while on the road and want to add those tracks to your desktop machine's archive? To do this, the sync program must accept your instructions about which device is the source and which the destination. So you must not get it wrong. In other words, in order to get the expected outcome, you must know how sync works.

To repeat your earlier point:

> Or consider your mobile device calendar. You add an appointment on your phone, it doesn't disappear when you sync with your PC (or with cloud, as is common today).

Yes, that's right, but you're not taking that example to its logical conclusion -- the smaller, more peripheral device, the phone, is the source for the sync. If that device has no music on it, the desktop machine will have its music collection erased.

> I didn't mean to imply that dictionary defines the meaning, but it does seem to agree with what I mean with "sync".

Yes, true, which explains why I've been hearing so many accounts like yours -- people rely on dictionaries to define technical terms and end up erasing their music collections.

> Where does this "true technical meaning of sync" come from?

Logical thinking:

1. "Sync" means that two directory trees end up with the same content -- exactly the same number of files, same names, same everything.

2. For (1) to be true, the program performing the sync must sometimes delete files as well as add files.

3. For (2) to be true, the program must know which directory tree is the source. Therefore the user must know this too. But users, reliant on dictionaries, may not understand what sync actually means.

Q.E.D.

Suppose I create appointment A on my phone's calendar, and appointment B on my laptop's calendar. After syncing, B shows up on my phone, and A shows up on my laptop (as I would expect). Who is the source and who is the target in this case?

According to your definition, this is not 'syncing'. But for most people, it is.

All synchronization depends on either the user, or a program, deciding which is the source and which is the destination. Such a choice is always made.

Consider this example:

1. Device A has a list of 9 contacts.

2. Device B has a list of 10 contacts.

3. According to your thesis, the sync program doesn't need to be told which is the source and which the target.

4. If so, and if the user intentionally deleted a contact from device A, shall the sync program:

x. Restore the contact missing from device A from device B, or

y. Delete the contact missing from device A from device B?

The answer is that the sync program cannot know what to do without being told which is the source and which is the destination.

This is how iTunes decides what to do -- the user tells it which is the source and which is the destination.

> According to your definition, this is not 'syncing'. But for most people, it is.

Yes, and to prove this point, and of the ascendancy of human instinct over logic, the OP lost his music collection.

This is a classic example of people's inability to think logically. How on earth could a computer program know what to do in the above example without being told what to do by the operator?

There's one exception, which ironically proves the point. In the example of real-time contact list synchronization, a sophisticated system would automatically assume that the device the operator is using at the moment, that he is editing, is the de facto source, and make other synchronized devices have the same content (this is how Google Contacts works). But in this example, as in all examples, the sync process cannot proceed until a decision is made about the meaning of "source" and "destination". In this example, the decision is automatic, but it has to be made.

In the case of syncing two music collections, the operator has to specifically identify which is the source and which the destination. I cannot tell you how often I've heard stories of people buying a new iPhone, then running iTunes, then erasing their music collection by misidentifying the source for the transaction.

If it happens that often then iTunes isn't communicating clearly enough to the user what is about to happen. I'm reminded of this advice:

> The principle is simple: it's not your fault. (Side note: if you don't understand this reference, then do yourself a favor and watch this video[1].) It's not your fault. It's not the user's fault. It's not the designer's fault. In fact, it's nobody's fault. What's crystal clear to you might be confusing to me, and no one is to blame for that. It's just something we have to work with. — Source: http://moz.com/blog/5-lessons-learned-from-100000-usability-...

[1] http://www.youtube.com/watch?v=dfXpRn8uFL8

> If it happens that often then iTunes isn't communicating clearly enough to the user what is about to happen.

Yes, I agree completely. But given that, I have to say I hear regularly from people who (a) buy a new iPhone, and then (b) wipe their music collections later on the same day.

Many people assume that an apparently sophisticated, polished program like ITunes will "do the right thing." But no.

4. If so, and if the user intentionally deleted a contact from device A, shall the sync program:

x. Restore the contact missing from device A from device B, or

y. Delete the contact missing from device A from device B?

Stop thinking in files and start thinking in actions, and the answer is obvious. The delete action is being synced, therefore the contact should be deleted from B. If the file is merely missing (e.g. due to filesystem corruption), it should be created from B, since you are syncing the create action.

There's no directionality needed or implied, it's a merge of two trees.

> The delete action is being synced, therefore the contact should be deleted from B.

Yes, and that is exactly what I said in my post, the one that got downvoted -- there are special cases where the context can be used to decide which is the source and which the destination. But a source and a destination must always be selected.

> There's no directionality needed or implied, it's a merge of two trees.

Not in the general case, because there is no general case. How do you merge two directory trees having different file sets without knowing the operator's wishes? Does he want files missing from one tree to be deleted from the other, or does he want files missing from one tree to be restored from the other? The answer is that you ask him -- the operation cannot proceed automatically.

And for this obvious, technically correct insight, my posts get downvoted with perfect reliability.

There is no source nor destination, it's a merge of two equivalent trees. When I do "git merge <remote>", I'm not saying I want to replace the local branch with contents of the remote, nor vice versa. There's no source nor destination, they're both equal.

How do you merge two directory trees having different file sets without knowing the operator's wishes? Does he want files missing from one tree to be deleted from the other, or does he want files missing from one tree to be restored from the other?

You're still thinking in files. There are no files, just actions. The files are a byproduct, not the things being synced.

> There is no source nor destination, it's a merge of two equivalent trees.

Let's say I have two systems in a programming project. On one of the systems, I have edited some files, but now realize I have created a bug I can't locate and I don't want to try to undo what I have done -- I just want system B to be returned to its original state, a state represented by system A, but with a minimum of file operations.

So I run a synchronization operation, and I tell the algorithm how to proceed. If I follow your philosophy --

"You're still thinking in files. There are no files, just actions. The files are a byproduct, not the things being synced."

-- then (using the default rules of two-way file synchronization), the edited files, the files I have ruined, files having newer dates than the originals, will be copied onto the original source tree, tree A, and I will lose the only remaining copies of the files' original states. If instead I delete the edited copies to avoid this, the originals will be deleted too.

So much for automatic file synchronization without the operator understanding and overseeing the process.

Your reply doesn't analyze file synchronization operations with enough depth to avoid such disasters.

You've moved your argument from "synchronization always must have a source and destination" to "certain synchronization models are not well suited to some use cases".

I certainly agree with the latter, even if it has no bearing on the former.

> You've moved your argument from "synchronization always must have a source and destination" to "certain synchronization models are not well suited to some use cases".

No, I have moved from specific examples to general examples, and general rules. The most general rule is that synchronization cannot be automatic and have a desirable outcome.

3. For (2) to be true, the program must know which directory tree is the source.

Nope. Both are the source of their own actions, and both are the destination of each other's. You're inventing restrictions that haven't applied since at least the first DVCSs.

Please do not contribute to public ignorance. You clearly haven't tried to use rsync, which has its name for a reason -- it's a synchronization utility. All synchronization operations must know which is the source and which the destination. Something this is arrived at automatically, but in the case of rsync and iTunes, you must tell it.

http://en.wikipedia.org/wiki/Rsync

Quote: "rsync is a file synchronization and file transfer program"

SO which word is confusing?

> Both are the source of their own actions, and both are the destination of each other's.

Of course. But let's return to planet Earth. Consider this example. Two systems have directories with independent collections of files. System A has 9 files. System B has 10 files. The operator tries to sync the two systems. But to do so, the operator has to tell his synchronization program, which is the source and which is the destination.

The outcome depends on the operator's decision, it cannot depend on the contents of the directory trees.

Read the original post, the one I replied to -- the OP lost his music collection by choosing the wrong source for a file synchronization operation using iTunes. I replied to explain what "synchronization" means in that context.

You clearly haven't tried to use rsync, which has its name for a reason -- it's a synchronization utility.

Like many others, e.g. Dropbox, Unison, Git-annex. Just because "rsync" has sync in it's name doesn't mean it's the only syncing model possible.

All synchronization operations must know which is the source and which the destination.

In rsync, yes. In others, no.

SO which word is confusing?

No confusing word. The only confusion is in the assumption that sync == rsync. It's like saying that all cars work like the Model T.

Two systems have directories with independent collections of files. System A has 9 files. System B has 10 files. The operator tries to sync the two systems. But to do so, the operator has to tell his synchronization program, which is the source and which is the destination.

Nope. You never have to tell Dropbox, Unison or git-annex which is the source and destination. In the latter, I just do "git-annex sync", and both are synced with each other.

>> All synchronization operations must know which is the source and which the destination.

> In rsync, yes. In others, no.

False. In a two-way synchronization, if the operator wants to restore an older version of a file because of a bad edit, he must tell the algorithm what to do. In no case can the operator use such an algorithm without understanding what rules it intends to apply.

> In the latter, I just do "git-annex sync", and both are synced with each other.

Read the above example. These programs must be told what to do by the operator, and there is no safe, automatic algorithm that always gets it right.

In a two-way synchronization, if the operator wants to restore an older version of a file because of a bad edit, he must tell the algorithm what to do.

I have no idea why are you bringing versioning into this conversation.

These programs must be told what to do by the operator, and there is no safe, automatic algorithm that always gets it right.

I don't know what do you mean by "get it right". That's a subjective concept.

All I'm saying it, syncing does not have to involve a "source" and a "destination", nothing else.

> I have no idea why are you bringing versioning into this conversation.

I can see that. Okay, let's say that someone has a corrupted music track on his iPhone, the track won't play, and even though it has a newer date than the original on his desktop archive, he needs to overwrite the new-date bad track with the old-date original.

> All I'm saying it, syncing does not have to involve a "source" and a "destination", nothing else.

All I am saying is you're not thinking about this with enough depth. In the above example, a modern, sophisticated two-way synchronization algorithm will overwrite the old-date good track with the new-date defective track unless the operator understands how synchronization works and prevents this default outcome.

> I don't know what do you mean by "get it right". That's a subjective concept.

No, it is not -- unless you think everything is a matter of opinion and there are no shared objective truths. And if you believe that, why do you even bother to post in public forums, forums that exist on the premise of the reality and utility of objective, shared truths?

Reply on news.ycombinator.com