Re: [Opensync-devel] file-sync patches

[Mark E. <ma...@mp...>]

On Mon, 2013-08-26 at 19:15 +0200, Graham Cobb wrote:
> On 26/08/13 15:40, Mark Ellis wrote:
> > filesync-escape-name.diff
> > Replace non-reversible substitution of characters that aren't valid as
> > filenames, with uri escaping. The old scheme resulted in unnecessary uid
> > changes, and could have given collisions and duplications.
> 
> I fairly strongly object to this change.
> 
> I seem to remember, a very, very long time ago (probably in Armin's day)
> a discussion of this (on the mailing list, or in a bug report, I don't
> remember).  I think the decision to use a non-reversible escape was made
> deliberately.
> 
> The reason was to make the filenames as human-usable as possible.
> File-sync is not intended to be used for interchange (use a proper
> protocol!), it is intended to be convenient and easy for humans, who may
> exchange (.ics, etc) files with each other.
> 
> By far the biggest problem is spaces.  Spaces are allowed in all
> filesystems we target but not in URLs.  They are also very common in the
> names of calendar and contact files.  We really, really, really don't
> want to fill the user's directory up with %20's!
> 
> The encoding has never been a problem in the real world.  But, if the
> decision is that we should move to a reversible encoding then we need to
> use something a bit more clever.
> 
> In that case, I suggest specifying a reserved_chars_allowed (to
> g_uri_escape_string) which includes at least space (probably " #$&(),",
> and possibly even "?!", although they are escaped today).
> 
> By the way, other programs (like my OWASync), and indeed human beings,
> use different (also non-reversible) algorithms. These have always
> inter-worked successfully with OpenSync.  I don't see the problem this
> is trying to fix.
> 
> Graham

I have no problem with an alternative scheme, but to my mind this is
currently broken.

For example, create a group to sync evolution and file. Evolution
commonly uses @ in it's uid scheme. Sync this group, anything that comes
from evo to file has @ replaced with _ in the resulting filename. This
has changed the uid, since file-sync stores the uid in the filename. Run
another sync, anything that had @ replaced with _ gets sent as a
deletion and an addition.

Now, I don't think it's up to opensync to change item uid's for no
reason, so this must be wrong. If file-sync is supposed to be usable in
the wild, then this kind of behaviour will confuse and worry people at
the least. If it's only for testing, then it's introducing artificial
artifacts into the testing process, which is also wrong.

Mark