headers
peter.hilber | 1 Jun 2006 15:39
Picon

Avoid "Proceed with propagating updates?" message if no changes are conflicting

Hi,
is there a way to avoid the "Proceed with propagating updates?" 
question when there are no conflicting changes?
When using -batch, I cannot specify anything for the conflicting 
changes. If not using -batch, then I always have to answer the 
question mentioned before.

Thanks
Peter

------------------------ Yahoo! Groups Sponsor --------------------~--> 
Get to your groups with one click. Know instantly when new email arrives
http://us.click.yahoo.com/.7bhrC/MGxNAA/yQLSAA/26EolB/TM
--------------------------------------------------------------------~-> 

 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/unison-users/

<*> To unsubscribe from this group, send an email to:
    unison-users-unsubscribe <at> yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
Permalink | Reply | 3 comments |
headers
Yu Safin | 1 Jun 2006 16:30
Picon

Restore after Disk failure

Hi list.
I have been using Unison on my Linux (2.9.1) to be the server and in
two XP machines (one is my desktop and the other is my laptop for when
I go on the road) to keep them synchronized.  When the disk on my
desktop failed, I had to rebuild the machine (I don't use Unison for
anything but my personal files, about 10 Gbytes) from scratch.  Then I
wen to my Linux server and copied the files that Unison keeps over to
my new disk.  I believe this was not the correct approach.  After I
installed Unison on my re-built machine, I can see that somehow things
got out of sync.  My laptop now believes that it cannot sync some
files (the dates are wrong).
I was thinking that since my desktop is the source of my files, I am
planning to delete my files from the laptop and run Unison from the
laptop to build everything from scratch.
any advise will be appreciated.

------------------------ Yahoo! Groups Sponsor --------------------~--> 
Home is just a click away.  Make Yahoo! your home page now.
http://us.click.yahoo.com/DHchtC/3FxNAA/yQLSAA/26EolB/TM
--------------------------------------------------------------------~-> 

 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/unison-users/

<*> To unsubscribe from this group, send an email to:
    unison-users-unsubscribe <at> yahoogroups.com
(Continue reading)

Permalink | Reply | 1 comment |
headers
Edward Grace | 1 Jun 2006 15:55
Picon

Bug found - Unicode equivalence

Dear All,

I have found a bug that I think should be fixed.  It concerns annoying
ambiguities between the way Linux treats two ways of representing an o
with umlaut against just one way for Mac OS X.  As with the case
insensitivity this leads to clashes.

If one understands the code I suspect the fix is probably reasonably
straightforward.  The bug is detailed here:

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=191295#c9

Along with a perl script to demonstrate the generation of two files with
clashing names.

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=191295#c8

To demonstrate this bug:

1) Download the perl script

==== cut =====
!/bin/perl

mkdir('Two_Files');
open(F1,"> Two_Files/\157\314\210.txt") or die "Can't open file \157\314\210.txt";
open(F2,"> Two_Files/\303\266.txt") or die "Can't open file \303\266.txt";

print F1 "This is the first file consiting of the composed letter, LATIN SMALL LETTER O + COMBINING DIAERESIS";
print F2 "This is the second file containing the composed letter, LATIN SMALL LETTER O WITH DIAERESIS";
(Continue reading)

Permalink | Reply | 7 comments |
headers
Wm... | 1 Jun 2006 16:55
Picon
Picon

Re: Avoid "Proceed with propagating updates?" message if no changes are conflicting

Thu, 1 Jun 2006 13:39:06 <e5mqlq+qhvk <at> eGroups.com>  peter.hilber 
<e0326179 <at> student.tuwien.ac.at>

>Hi,
>is there a way to avoid the "Proceed with propagating updates?"
>question when there are no conflicting changes?
>When using -batch, I cannot specify anything for the conflicting
>changes. If not using -batch, then I always have to answer the
>question mentioned before.

if you are very sure try silent

--

-- 
Wm ...
Please reply to the list
e-mail replies will be replied to in the list unless marked as private

------------------------ Yahoo! Groups Sponsor --------------------~--> 
Get to your groups with one click. Know instantly when new email arrives
http://us.click.yahoo.com/.7bhrC/MGxNAA/yQLSAA/26EolB/TM
--------------------------------------------------------------------~-> 

 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/unison-users/

<*> To unsubscribe from this group, send an email to:
    unison-users-unsubscribe <at> yahoogroups.com
(Continue reading)

Permalink | Reply | 2 comments |
headers
Wm... | 1 Jun 2006 17:26
Picon
Picon

Re: Bug found - Unicode equivalence

Thu, 1 Jun 2006 14:55:11 
<1149170111.10989.5.camel <at> ptpc3lin.op.ph.ic.ac.uk>  Edward Grace 
<ej.grace <at> imperial.ac.uk>

>I have found a bug that I think should be fixed.  It concerns annoying
>ambiguities between the way Linux treats two ways of representing an o
>with umlaut against just one way for Mac OS X.  As with the case
>insensitivity this leads to clashes.

[snip]

>2) Run it on a Linux system.  This will generate a directory Two_Files, 
>containing two files.
>
>3) Do a Unison sync between that machine and a Mac OS X system.
>
>4) This will trigger the bug, since the two files resolve to the same 
>name on OS X.
>
>I hope this helps people track and squash this particularly obscure beastie!

Is the problem not with OSX rather than Unison?

If you sync from OSX to Linux you will get one file.

If you have two files on Linux and sync to OSX and OSX can't handle that 
surely Unison isn't the problem?

Or have I misunderstood?  What are you expecting Unison to do?
(Continue reading)

Permalink | Reply | 6 comments |
headers
Benjamin Pierce | 1 Jun 2006 17:59
Favicon

Re: Bug found - Unicode equivalence

I agree with Edward that this should be viewed as a bug in Unison:  
the situation is indeed just the same as with syncing case-sensitive  
filesystems with "case preserving but insensitive" ones.  Unison goes  
to considerable trouble to handle the latter situation correctly, but  
(as Edward discovered) not the former.

Unfortunately, I'm less sanguine about the ease of fixing things.   
There are lots of ways in which Unison doesn't deal well with Unicode  
and other character encoding issues -- basically, Unison itself just  
ignores all such issues and takes whatever it gets from the lower- 
level OCaml / Posix filesystem libraries, string libraries, etc.   
Doing all of this right would be very valuable, but at the moment no  
one is signed up to do it.  (Volunteers welcome, of course! :-)

Regards,

      - Benjamin

On Jun 1, 2006, at 11:26 AM, Wm... wrote:

> Thu, 1 Jun 2006 14:55:11
> <1149170111.10989.5.camel <at> ptpc3lin.op.ph.ic.ac.uk>  Edward Grace
> <ej.grace <at> imperial.ac.uk>
>
>> I have found a bug that I think should be fixed.  It concerns  
>> annoying
>> ambiguities between the way Linux treats two ways of representing  
>> an o
>> with umlaut against just one way for Mac OS X.  As with the case
>> insensitivity this leads to clashes.
(Continue reading)

Permalink | Reply | 2 comments |
headers
peter.hilber | 1 Jun 2006 19:12
Picon

Re: Avoid "Proceed with propagating updates?" message if no changes conflicting

--- In unison-users <at> yahoogroups.com, "Wm..." <wm-unison <at> ...> wrote:
>
> Thu, 1 Jun 2006 13:39:06 <e5mqlq+qhvk <at> ...>  peter.hilber 
> <e0326179 <at> ...>
> 
> >Hi,
> >is there a way to avoid the "Proceed with propagating updates?"
> >question when there are no conflicting changes?
> >When using -batch, I cannot specify anything for the conflicting
> >changes. If not using -batch, then I always have to answer the
> >question mentioned before.
> 
> if you are very sure try silent
> 

According to the doc, "silent to true automatically sets the batch 
preference to true". The only difference to batch I observed is that 
now only the conflicts are output, but you still can't resolve them. :
(

------------------------ Yahoo! Groups Sponsor --------------------~--> 
Get to your groups with one click. Know instantly when new email arrives
http://us.click.yahoo.com/.7bhrC/MGxNAA/yQLSAA/26EolB/TM
--------------------------------------------------------------------~-> 

 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/unison-users/
(Continue reading)

Permalink | Reply | 1 comment |
headers
Edward Grace | 1 Jun 2006 19:12
Picon

Re: Bug found - Unicode equivalence

> If you have two files on Linux and sync to OSX and OSX can't handle  
> that
> surely Unison isn't the problem?

Hi.  As Benjamin points out in another post this is a more complex  
superset of the problem with case sensitive / case insensitive file  
systems.  The "blame" is not really an issue of OS X vs Linux, the  
two systems simply have different assumptions and conventions  
regarding their files.  Quite frankly I don't think either is  
inherently right or wrong, they are just different.

> Or have I misunderstood?  What are you expecting Unison to do?

I think you have misunderstood.

As eluded to by Benjamin, a complete machine independent Unicode  
layer between the file system and unison is likely to be "involved".   
I think, on balance, that it is right for Unison to rely on the  
system libraries, however I think the default behaviour for a  
filename clash is incorrect.

I expect unison to accept that there will be the possibility of  
filename clashes, or problem filenames and to act gracefully.  If  
this is the default, then managing case insensitivity should come for  
free!

If I understand correctly the process of failure is as follows:

1) The source list of files to transfer from Linux -> Mac OSX goes  
over.  There are two distinct file names in this byte stream.  They
(Continue reading)

Permalink | Reply | 2 comments |
headers
Fred Frigerio | 1 Jun 2006 20:43

RE: Bug found - Unicode equivalence

I would expect Unison to fail gracefully?

Fred Frigerio
Locust USA

This electronic message transmission contains information from Locust USA which may be confidential or
privileged.  The information is intended to be for the use of the individual or entity named above.  If you
are not the intended recipient, be aware that any disclosure, copying, distribution or use of the
contents of this information is prohibited.  If you have received this electronic transmission in error,
please notify us by telephone (305-889-5410) or by reply via electronic mail immediately.

> -----Original Message-----
> From: Wm... [mailto:wm-unison <at> tarrcity.demon.co.uk] 
> Sent: Thursday, June 01, 2006 11:26 AM
> To: unison-users <at> yahoogroups.com
> Subject: Re: [unison-users] Bug found - Unicode equivalence
> 
> Thu, 1 Jun 2006 14:55:11
> <1149170111.10989.5.camel <at> ptpc3lin.op.ph.ic.ac.uk>  Edward 
> Grace <ej.grace <at> imperial.ac.uk>
> 
> >I have found a bug that I think should be fixed.  It 
> concerns annoying 
> >ambiguities between the way Linux treats two ways of 
> representing an o 
> >with umlaut against just one way for Mac OS X.  As with the case 
> >insensitivity this leads to clashes.
> 
> [snip]
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Kai Steinbach | 2 Jun 2006 11:54
Picon
Gravatar

Re: Bug found - Unicode equivalence

Hi Benjamin,

this topic has popped up in the mailing list a few times before, so I
thought it's worth putting it into a little FAQ page:
http://alliance.seas.upenn.edu/~bcpierce/unison/wiki/index.php?n=Main.UnisonFAQCharacterEncoding

I left some room for others to contribute with the experience of their
environments, as well as ways to make it easy to work around this
limitation. Are there any python / perl scripts to automate renaming a
whole tree out there? I might polish and publish my own
rename_to_ascii.vbs some day ... though this would only help the
windows guys, sorry. :(

Final note: I have my fingers crossed that one day someone can spend
the time on the OCaml / Posix basis and Unison and make it all just do
The Right Thing. That would be great ;-)

Regards,
Kai

On 6/1/06, Benjamin Pierce <bcpierce <at> cis.upenn.edu> wrote:
[snip]
> Unfortunately, I'm less sanguine about the ease of fixing things.
> There are lots of ways in which Unison doesn't deal well with Unicode
> and other character encoding issues -- basically, Unison itself just
> ignores all such issues and takes whatever it gets from the lower-
> level OCaml / Posix filesystem libraries, string libraries, etc.
> Doing all of this right would be very valuable, but at the moment no
> one is signed up to do it.  (Volunteers welcome, of course! :-)
(Continue reading)

Permalink | Reply | 0 comments |

Gmane