headers
ectanna2001 | 1 Jul 2010 14:49
Picon
Favicon

Re: Fatal error: Warning: the previous run of unison terminated in a dangerous state

I still haveing a problem after tried with version 2.40, can someone help please !

As I mentioned:
- I do have 2 location of the folders (Q: and local drive e.g.D:/Program Files/Aastra/Oas/root_container
) and normally Unison synchonize file for me perfectly.
- But if the file is opened by application on a local drive then a new copied file on Q: drive (same file name but
has updated content) would NOT be able to replicate to local drive.
- I can see a new copied file for example ".unison.TC1.wav..001..33b7d2.unison.tmp" was created on the
local drive, and got error in Unison log.

=====
Failed: Error in renaming C:/Program Files/Aastra/OAS/root_container/TC1.wav to C:/Program Files/Aastra/OAS/root_container/.unison.TC1.wav..001..33b7d2.unison.tmp:
Permission denied [rename(C:/Program Files/Aastra/OAS/root_container/TC1.wav)]
=====

- As soon as file is closed by application then file is replicated to local drive okay.

I have tried with the CreateFile API with the FILE_SHARE_DELETE option but the behavior is same.
The problem here is not with renaming but Unison is not able to updating the file which is in use.

Unsion is not able to update the file if the handle count is > 1, when the handle counts becomes zero then
Unsion is updating the file.

What is Unison trying to do in case of updating file actually ? I tested and I'm sure that file can be renamed
while file is opened by application, so there should not be a problem on the window level.
But some how Unison cannot updating file.

Can please someone advice.
Br.Anek
(Continue reading)

Permalink | Reply | 1 comment |
headers
Jerome Vouillon | 1 Jul 2010 21:03
Picon

Re: Re: Fatal error: Warning: the previous run of unison terminated in a dangerous state

On Thu, Jul 01, 2010 at 12:49:53PM -0000, ectanna2001 wrote:
> What is Unison trying to do in case of updating file actually ? I
> tested and I'm sure that file can be renamed while file is opened by
> application, so there should not be a problem on the window level.
> But some how Unison cannot updating file.

Unison first makes a copy of the source file to a temporary location.
In your case, this is file ".unison.TC1.wav..001..33b7d2.unison.tmp".
Then, it attempts to replace the previous version of the destination
file by this copy.  Under Windows, this is done in three steps: first
the previous version is moved out of the way; second, the copy is
moved to the destination location; third, the previous version is
deleted.  According to your error message, the first step fails.  We
are using the following function, which seems to be the standard way
of renaming files under Windows:

  MoveFileExW(wpath1, wpath2, MOVEFILE_REPLACE_EXISTING)

So, it seems that opened files cannot be renamed under Windows.

-- Jerome

------------------------------------

Yahoo! Groups Links

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

<*> Your email settings:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jerome Vouillon | 1 Jul 2010 21:12
Picon

Re: Feature request: option for progressive update of archive files

On Mon, Jun 28, 2010 at 02:20:38PM -0000, jpmcgee_hm wrote:
> I use Unison to copy big disks (> 1 TB) with hundreds of big files
> (10-20 GB). It can take up to a day for Unison to just scan the
> files before it starts copying. Once it starts copying, if I have to
> kill it before it completes, it takes even longer to scan because
> now it has some already copied files to scan.
>
> If Unison had an option where it would make progressive updates to
> the archive file instead of waiting until the end, it would save me
> several hours to maybe a day each time. I do it a few times per
> year, and I end up having to kill a partial copy about every other
> or third time.

Please try the beta release, Unison 2.40 (and report back if you have
any problem with it or comments).  It does not quite do progressive
updates, but it caches file fingerprints on-disk.  Thus, when it is
interrupted during update detection, it does not have to rescan the
contents of files it has already scanned.  This is not yet perfect, as
it will still scan the files it has copied if you interrupt it during
propagation, but that should be a big improvement nonetheless.

-- Jerome

------------------------------------

Yahoo! Groups Links

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

Permalink | Reply | 0 comments |
headers
Nick Cummings | 1 Jul 2010 23:30
Picon
Favicon

Unison Usage Questions

Hi,

I've been a highly satisfied Unison user for quite a while, but I think I've only really used its basic
functionality, so I'm writing to get an idea of how best to use it for slightly more complicated tasks.  So
far, I've used Unison to sync 2 Linux boxes that are always available via ssh.  I always run Unison from the
same machine, and I use the backup option to keep a backup version of files that are updated (so that if I am
overly hasty and overwrite something I shouldn't I can recover).  I'm trying to understand a couple of points:

1) If I run unison from machine A to sync with machine B, then it creates an archive file in the .unison
directory on machine A recording the current state of each root. If I were run unison on machine B with a
profile setup to sync the same roots in exactly the same way, am I correct in thinking that it would keep a
totally independent archive file, totally unaware of the one that already exists on machine A?  Would this
sort of usage cause any problems (say, because when I run unison on machine B it will mean that when I next run
unison on machine A it will find changes made on both sides)?  As I said, I currently always run Unison from
the same machine (from the terminal via ssh if necessary), but there would be advantages to just running
the program locally every time.

2) When I turn on the backup feature, are all the backups are kept on the local machine where unison is run
(even if the version of the file being backed up is the one being overwritten on the remote machine)?  Is this
true even when the profile specifies "backuplocation = local"?

3) If I wish to sync the same path on machine A with corresponding paths on machine B and on machine C, is the
correct usage to create two separate profiles on machine A (one for syncing to machine B and one for machine
C)? If I use the backup feature, do I need to specify a different backup location in each profile in order to
keep straight which backup of a file corresponds to which remote machine?

I appreciate any help on this stuff.  I have looked at the Unison documentation, but these things still
weren't 100% clear to me.  If any of the devs read this list, I'd just like to express my thanks for a wonderful
piece of software that has freed me from the hell of trying to manually keep things synced while not asking
me to give up my privacy.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Alan Schmitt | 2 Jul 2010 09:56

Re: Unison Usage Questions

On 1 juil. 2010, at 23:30, Nick Cummings wrote:

> 1) If I run unison from machine A to sync with machine B, then it creates an archive file in the .unison
directory on machine A recording the current state of each root. If I were run unison on machine B with a
profile setup to sync the same roots in exactly the same way, am I correct in thinking that it would keep a
totally independent archive file, totally unaware of the one that already exists on machine A?

No, as archives are on both machines (and are identical). So where you initiate the synchronization does
not matter, as long as the names of the machines do not change.

> 2) When I turn on the backup feature, are all the backups are kept on the local machine where unison is run
(even if the version of the file being backed up is the one being overwritten on the remote machine)?  Is this
true even when the profile specifies "backuplocation = local"?

Yes, backups are stored on the client (i.e., where you are starting unison from). The "backuplocation"
preference changes where (in the file system) backups are kept: in a centralized location (I think it's
"global"), or along the files ("local").

> 3) If I wish to sync the same path on machine A with corresponding paths on machine B and on machine C, is the
correct usage to create two separate profiles on machine A (one for syncing to machine B and one for machine
C)? If I use the backup feature, do I need to specify a different backup location in each profile in order to
keep straight which backup of a file corresponds to which remote machine?

You need to create two profiles. You can have a common profile that you "include" in the two profiles which
would then only mention the roots.

I don't know about the backups.

Hope this helps,
(Continue reading)

Permalink | Reply | 2 comments |
headers
Jerome Vouillon | 2 Jul 2010 10:56
Picon

Re: Unison Usage Questions

On Fri, Jul 02, 2010 at 09:56:16AM +0200, Alan Schmitt wrote:
> > 2) When I turn on the backup feature, are all the backups are kept on the local machine where unison is run
(even if the version of the file being backed up is the one being overwritten on the remote machine)?  Is this
true even when the profile specifies "backuplocation = local"?
> 
> Yes, backups are stored on the client (i.e., where you are starting
> unison from).

Actually, backups are stored on both sides.

-- Jerome

------------------------------------

Yahoo! Groups Links

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

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/unison-users/join
    (Yahoo! ID required)

<*> To change settings via email:
    unison-users-digest <at> yahoogroups.com 
    unison-users-fullfeatured <at> yahoogroups.com
(Continue reading)

Permalink | Reply | 1 comment |
headers
Alan Schmitt | 2 Jul 2010 11:07

Re: Unison Usage Questions

On 2 juil. 2010, at 10:56, Jerome Vouillon wrote:

> On Fri, Jul 02, 2010 at 09:56:16AM +0200, Alan Schmitt wrote:
>>> 2) When I turn on the backup feature, are all the backups are kept on the local machine where unison is run
(even if the version of the file being backed up is the one being overwritten on the remote machine)?  Is this
true even when the profile specifies "backuplocation = local"?
>> 
>> Yes, backups are stored on the client (i.e., where you are starting
>> unison from).
> 
> Actually, backups are stored on both sides.

Thanks for the correction, I did not know that!

Alan

------------------------------------

Yahoo! Groups Links

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

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/unison-users/join
    (Yahoo! ID required)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ben Stover | 6 Jul 2010 12:19
Picon
Favicon

Sync of two dirs through an intermediate 3rd diff. dir possible?

I am searching for solution for a special scenario: 

I have two notebooks (resp two external backup USB harddiscs). 
These two notebooks are very seldom directly connected within the same LAN. So a direct Unison
synchronization of a special very big directory tree on 
each of them cannot be performed. 

However from time to time they are connected to a third desktop computer. I am searching now for a way to sync
these two notebook directory trees 
through the intermediate third desktop computer. 

Because of the size of the directory trees the desktop computer should NOT keep all the full content as a
"master repository". Instead it should just hold the 
difference of files+folders which needs to be synced to the other notebook. 

Example: Lets start both notebook directories with 10 files 
file1.dat, file2.dat,.......,file10.dat 

Now I delete on notebook1 the file7.dat and add a file11.dat 
When connected to the intermediate desktop computer the Unison installation there should recognize the
changes. 
- A todo entry should be created "delete file7.dat on notebook2" 
- file11.dat should be copied to the desktop computer and a second 
todo entry should be created "copy file11.dat to notebook2" 

Later (in a few days) when notebook2 is connected to the third intermediate Unison broker installation the
pending todo tasks should be performed. 

Is this somehow possible with Unison ? 
If yes: How exactly can I setup such a broker function?
(Continue reading)

Permalink | Reply | 1 comment |
headers
Evert Mouw | 6 Jul 2010 08:51

hash before delete

  This is a curious problem. The xferbycopying will not work when:
- the target has new file named B
- the source has new file named A
- file contents (A) = file contents (B)
- all changes are propagated from source to target

I got this problem after copying lots of video files from my NTFS drive 
to an ext2 formatted drive using Ext2fsd (an ext2 driver for Windows). I 
brought the ext2-formatted drive to my remote Linux server, converted it 
to ext4, and ran Unison. I got an error about some non-unicode formatted 
filenames, so I used convmv to convert those filenames to UTF8, but 
maybe something did go wrong, because now I get loads of cases like this 
one:

new file --->                   Motörhead - Brave new World.avi
               ---> new file     Mot???rhead - Brave new World.avi

When syncing, I would expect that syncing could be very fast because the 
file contents of "Mot???rhead - Brave new World.avi" are exactly the 
same as "Motörhead - Brave new World.avi". But no, the whole file will 
be copied over the network. Because the network is slow (1 mbps uplink, 
and many gigabytes of data), I wonder how I could trick Unison to hash 
all files before they will be deleted, so xferbycopying will speed up 
the operation.

I use these versions:
Windows source = unison version 2.39.4
Linux target = unison version 2.39.0

Any ideas?
(Continue reading)

Permalink | Reply | 3 comments |
headers
Evert Mouw | 6 Jul 2010 14:05

hash before delete (2)

(2nd mail; 1st mail did not arrive on yahoo groups, failed without an 
error, don't know what went wrong)

This is a curious problem. The xferbycopying will not work when:
- the target has new file named B
- the source has new file named A
- file contents (A) = file contents (B)
- all changes are propagated from source to target

I got this problem after copying lots of video files from my NTFS drive 
to an ext2 formatted drive using Ext2fsd (an ext2 driver for Windows). I 
brought the ext2-formatted drive to my remote Linux server, converted it 
to ext4, and ran Unison. I got an error about some non-unicode formatted 
filenames, so I used convmv to convert those filenames to UTF8, but 
maybe something did go wrong, because now I get loads of cases like this 
one:

new file --->                   Motörhead - Brave new World.avi
               ---> new file     Mot???rhead - Brave new World.avi

When syncing, I would expect that syncing could be very fast because the 
file contents of "Mot???rhead - Brave new World.avi" are exactly the 
same as "Motörhead - Brave new World.avi". But no, the whole file will 
be copied over the network. Because the network is slow (1 mbps uplink, 
and many gigabytes of data), I wonder how I could trick Unison to hash 
all files before they will be deleted, so xferbycopying will speed up 
the operation.

I use these versions:
Windows source = unison version 2.39.4
(Continue reading)

Permalink | Reply | 1 comment |

Gmane