1 |
On 7/31/05, Neil Bothwick <neil@××××××××××.uk> wrote: |
2 |
> On Sun, 31 Jul 2005 13:43:16 -0700, Mark Knecht wrote: |
3 |
> |
4 |
> > One possibly tricky part about this will be that in some cases we |
5 |
> > have found bad rips and have reripped files to fix that. In this case |
6 |
> > there is going to be a newer file in each either location with the |
7 |
> > same name but with a new size & date. Will Unison give me an option to |
8 |
> > just accept the newer one in each location and remove or backup the |
9 |
> > older one automatically? |
10 |
> |
11 |
> Unison is particularly good at handling this sort of situation. It keeps |
12 |
> a log of the file dates each time you sync and asks for manual |
13 |
> intervention when a file have been updated on both sides since the last |
14 |
> sync. |
15 |
> |
16 |
|
17 |
Hi Neil, |
18 |
OK, so I tried Unison and, twice, it just gets stuck at the same |
19 |
file. I'm running it like this: |
20 |
|
21 |
unison /home/mark/music /mnt/Musiclib |
22 |
|
23 |
The gui comes up and the program gets started but then it just hangs. |
24 |
There's no obvious network activity or local disk activity. If I let |
25 |
the program sit long enough for the screensaver to kick in then when I |
26 |
unlock the screen the program is just a grey box. |
27 |
|
28 |
So far I cannot even kill the thing. kill -9 pid or killall -9 unison |
29 |
act like they killed it but ps aux says the process is still there. |
30 |
It's even there if I try killing the gui in Gnome. The gui goes away |
31 |
but the process persists. |
32 |
|
33 |
Any ideas on what I'm doing wrong? |
34 |
|
35 |
Thanks, |
36 |
Mark |
37 |
|
38 |
-- |
39 |
gentoo-user@g.o mailing list |