[unison-users] Unison permissions

[Isaac Witmer [e-mail] [unison-users]]

I use unison to synchronize scripts (and various other things) between
servers, and computers I use.

I've found quite a few times where the execution bit on my scripts seems to
have switched for no apparent reason, other than editing the file in vim.
I think the problem is unison, because often after editing my bash scripts,
I use them immediately, and it's not till the next day I notice that
they're marked -x again.

Does anyone else experience this? Is there any suggestions on how to
prevent it?

-Isaac

[Alan Schmitt [e-mail] [unison-users]]

Post by Isaac Witmer ***@gmail.com [unison-users]
I use unison to synchronize scripts (and various other things) between
servers, and computers I use.
I've found quite a few times where the execution bit on my scripts seems to
have switched for no apparent reason, other than editing the file in vim.
I think the problem is unison, because often after editing my bash scripts,
I use them immediately, and it's not till the next day I notice that
they're marked -x again.
Does anyone else experience this? Is there any suggestions on how to
prevent it?

I haven't seen it. Can you look at the logs and see if it's unison that
changes it? If so, can you tell us what OS the servers run, and send us
the profile you use for the synchronization.

Best,

Alan

[Benoît-Pierre Demaine [e-mail] [unison-users]]

One host could be using a file system with execution disabled on the partition. Check if one host has noexec in the mount options.

Anyway, log must say.

Also check in which way you are going (direction of sync ).

Post by Isaac Witmer ***@gmail.com [unison-users]

Post by Isaac Witmer ***@gmail.com [unison-users]
I use unison to synchronize scripts (and various other things)

between

Post by Isaac Witmer ***@gmail.com [unison-users]
servers, and computers I use.
I've found quite a few times where the execution bit on my scripts

seems to

Post by Isaac Witmer ***@gmail.com [unison-users]
have switched for no apparent reason, other than editing the file in

vim.

Post by Isaac Witmer ***@gmail.com [unison-users]
I think the problem is unison, because often after editing my bash

scripts,

Post by Isaac Witmer ***@gmail.com [unison-users]
I use them immediately, and it's not till the next day I notice that
they're marked -x again.
Does anyone else experience this? Is there any suggestions on how to
prevent it?

I haven't seen it. Can you look at the logs and see if it's unison that
changes it? If so, can you tell us what OS the servers run, and send us
the profile you use for the synchronization.
Best,
Alan
--
OpenPGP Key ID : 040D0A3B4ED2E5C7
Monthly Athmospheric CO₂, Mauna Loa Obs. 2017-07: 407.07, 2016-07: 404.39

-- Benoît-Pierre Demaine. Typos sponsorisées par mon téléphone.

[Alan Schmitt [e-mail] [unison-users]]

Post by Alan Schmitt ***@polytechnique.org [unison-users]
Can you look at the logs

Thanks for the idea. I found two different files that both had the
execution bit switched, and I'll keep checking others for a pattern, but
the pattern currently seems to be missing 'unison.tmp' files.

Post by Alan Schmitt ***@polytechnique.org [unison-users]
No such file or directory

[utimes(/home/isaac/.bin/.unison.archive_backups.40f3b2519c00f4ebf41528310378e88e.unison.tmp)]

Are you synchronizing the archives?

And now I realize that I wrote a script a long time ago to go through the
folders I sync (on my server) and delete all unison.tmp files that it
leaves lying around on the hour. So it's probably that along with some
kind of timing.
I've disabled that script and we'll see if that fixes the issue. And then
I'll find out if I need to find some other solution to handle those
unison.tmp files, or if Unison is handling them better.

I think Unison is now better at cleaning tmp files.

Best,

Alan

[[e-mail] [unison-users]]

Post by Isaac Witmer ***@gmail.com [unison-users]
I've found quite a few times where the execution bit on my scripts seems to
have switched for no apparent reason, other than editing the file in vim.
I think the problem is unison, because often after editing my bash scripts,
I use them immediately, and it's not till the next day I notice that
they're marked -x again.

If this always happens among a small group of files, the thing to do is,
every day, take a complete directory listing of the files *on all the
computers*. Then, when you notice an x bit missing, you can compare the
previous day's listing to see what copies Unison should have done
between the computers. Then look at the Unison logs to see what copies
Unison did do. Then look at today's listings to see what the
consequences are. That should make it clear which particular copy is
not doing what you want, and you can investigate why.

Dale

[[e-mail] [unison-users]]

And now I realize that I wrote a script a long time ago to go through the
folders I sync (on my server) and delete all unison.tmp files that it
leaves lying around on the hour. So it's probably that along with some
kind of timing.

That sort of thing works fine, as long as you delete all unison.tmp
files *that haven't been accessed in a day or so*. E.g.,

find ...dir... -name '*.unison.tmp' -atime +1 | xargs --no-run-if-empty rm

Dale

[Benoît-Pierre DEMAINE [e-mail] [unison-users]]

Post by Isaac Witmer ***@gmail.com [unison-users]
I use unison to synchronize scripts (and various other things) between
servers, and computers I use.
I've found quite a few times where the execution bit on my scripts seems
to have switched for no apparent reason, other than editing the file in vim.
I think the problem is unison, because often after editing my bash
scripts, I use them immediately, and it's not till the next day I notice
that they're marked -x again.
Does anyone else experience this? Is there any suggestions on how to
prevent it?
-Isaac

This kind of bug may depend on your user options:
- are you editing with the same user as owner of file ? sudo ? su ?
- did you check the full stats of file before and after edition (owner and
properties)
- what is your exact unison sync line ? (regarding user management)

I have found properties were altered when owners had troubles: edit file
on host A; sync it to B; user does not have the same name or ID on both
machines, so, unison will mess owner; new owner may not have permissions
to create X files on this filesystem (see mount options), so unison on B
side will either change owner, or perms of file. On next sync, this is
backported on A.

1: carefully read your full sync logs. Verbose logs always report this
kind of issue.

2: always run TWICE in a row your sync script (all machines once, then,
all machines a second time).

[Isaac Witmer [e-mail] [unison-users]]

This is hard to debug. Maybe I do need to increase my verbosity or
something.

It happened again, this time with a conflict, so I was able to check it
better:
local tesla
changed <-?-> props home/isaac/.bin/git-do-review [] x
local : changed file modified on 2017-10-25 at 17:07:40 size
2466 rwx--x--x
tesla : changed props modified on 2017-10-25 at 17:11:05 size
2475 rw-------
changed <-?-> props home/isaac/.bin/git-do-review []


"Luckily" there was a conflict, so I noticed it before it propagated
further.

My laptop (the other computer in this set that would have synced this file)
has these messages in the log:

UNISON 2.48.3 started propagating changes at 16:51:00.32 on 25 Oct 2017
[BGN] Updating file home/isaac/.bin/git-do-review from
//tesla//media/psi/sync to /
[BGN] Updating file home/isaac/.bin/git-do-review from
//tesla//media/psi/sync to /
<-- snip -- some files here -->
Failed: Error in setting modification time:
No such file or directory
[utimes(/home/isaac/.bin/.unison.git-do-review.40f3b2519c00f4ebf41528310378e88e.unison.tmp)]
[END] Updating file home/isaac/.bin/git-do-review
<-- snip -- some files here -->
UNISON 2.48.3 finished propagating changes at 16:51:00.34 on 25 Oct 2017
Synchronization incomplete at 16:51:00 (4 items transferred, 0 skipped, 1
failed)
failed: home/isaac/.bin/git-do-review
UNISON 2.48.3 started propagating changes at 16:51:02.19 on 25 Oct 2017
[BGN] Copying properties for home/isaac/.bin/git-do-review from / to
//tesla//media/psi/sync
[BGN] Copying properties for home/isaac/.bin/git-do-review from / to
//tesla//media/psi/sync
[END] Copying properties for home/isaac/.bin/git-do-review
[END] Copying properties for home/isaac/.bin/git-do-review
UNISON 2.48.3 finished propagating changes at 16:51:02.19 on 25 Oct 2017
Synchronization complete at 16:51:02 (2 items transferred, 0 skipped, 0
failed)
UNISON 2.48.3 started propagating changes at 17:01:03.99 on 25 Oct 2017
<-- snip -- some files here -->
UNISON 2.48.3 finished propagating changes at 17:01:04.03 on 25 Oct 2017
Synchronization complete at 17:01:04 (6 items transferred, 0 skipped, 0
failed)
UNISON 2.48.3 started propagating changes at 17:11:05.93 on 25 Oct 2017
[BGN] Updating file home/isaac/.bin/git-do-review from
//tesla//media/psi/sync to /
[BGN] Updating file home/isaac/.bin/git-do-review from
//tesla//media/psi/sync to /
<-- snip -- some files here -->
Failed: Error in setting modification time:
No such file or directory
[utimes(/home/isaac/.bin/.unison.git-do-review.40f3b2519c00f4ebf41528310378e88e.unison.tmp)]
[END] Updating file home/isaac/.bin/git-do-review
<-- snip -- some files here -->
UNISON 2.48.3 finished propagating changes at 17:11:05.96 on 25 Oct 2017
Synchronization incomplete at 17:11:06 (7 items transferred, 0 skipped, 1
failed)
failed: home/isaac/.bin/git-do-review
UNISON 2.48.3 started propagating changes at 17:11:07.81 on 25 Oct 2017
[BGN] Copying properties for home/isaac/.bin/git-do-review from / to
//tesla//media/psi/sync
[BGN] Copying properties for home/isaac/.bin/git-do-review from / to
//tesla//media/psi/sync
[END] Copying properties for home/isaac/.bin/git-do-review
[END] Copying properties for home/isaac/.bin/git-do-review


Is it significant that there's two references to copying end ending the
copy?
I can't figure out why it keeps failing to find the file...
I wonder if that's the reason.


-Isaac

Post by Isaac Witmer ***@gmail.com [unison-users]
I use unison to synchronize scripts (and various other things) between
servers, and computers I use.
I've found quite a few times where the execution bit on my scripts seems
to have switched for no apparent reason, other than editing the file in vim.
I think the problem is unison, because often after editing my bash
scripts, I use them immediately, and it's not till the next day I notice
that they're marked -x again.
Does anyone else experience this? Is there any suggestions on how to
prevent it?
-Isaac
- are you editing with the same user as owner of file ? sudo ? su ?
- did you check the full stats of file before and after edition (owner and
properties)
- what is your exact unison sync line ? (regarding user management)
I have found properties were altered when owners had troubles: edit file
on host A; sync it to B; user does not have the same name or ID on both
machines, so, unison will mess owner; new owner may not have permissions to
create X files on this filesystem (see mount options), so unison on B side
will either change owner, or perms of file. On next sync, this is
backported on A.
1: carefully read your full sync logs. Verbose logs always report this
kind of issue.
2: always run TWICE in a row your sync script (all machines once, then,
all machines a second time).
--

Post by Isaac Witmer ***@gmail.com [unison-users]
o_/ DEMAINE Benoît-Pierre (aka DoubleHP) http://benoit.demaine.info/

If computing were an exact science, IT engineers would'nt have work \_o<
"So all that's left, Is the proof that love's not only blind but deaf."
(FAKE TALES OF SAN FRANCISCO, Arctic Monkeys)

[Isaac Witmer [e-mail] [unison-users]]

Ok, I finally found a good example.

My periodic run (unison -batch -repeat 600) had a conflict:
Synchronization complete at 17:57:59 (6 items transferred, 2 skipped, 0
failed)
skipped: home/isaac/.bin/vs/git_plugins/git-do-review (contents changed
on both sides)
skipped: home/isaac/.bin/vs/git_plugins/git-do-review (contents changed
on both sides)

So I run it manually:

local tesla
props <-?-> changed home/isaac/.bin/vs/git_plugins/git-do-review [] x
local : changed props modified on 2018-01-02 at 15:21:58 size
3211 rw-------
tesla : changed file modified on 2018-01-02 at 15:24:10 size
3012 rwx--x--x
props <-?-> changed home/isaac/.bin/vs/git_plugins/git-do-review [] d

diff -u '/home/isaac/.bin/vs/git_plugins/git-do-review.unison.diff-'
'/home/isaac/.bin/vs/git_plugins/git-do-review'
.... bash code here... it's too ugly to show ...

Looks like there's a permissions difference, and a file size difference.
Let's propagate:

props <==== changed home/isaac/.bin/vs/git_plugins/git-do-review [] ,
props <==== changed home/isaac/.bin/vs/git_plugins/git-do-review [] ,
changed ----> home/isaac/.bash_history

Ok, a bit confused why it shows up twice... continuing anyway...

Proceed with propagating updates? [] y[BGN] Updating file
home/isaac/.bin/vs/git_plugins/git-do-review from //tesla//media/psi/sync
to /
[BGN] Updating file home/isaac/.bin/vs/git_plugins/git-do-review from
//tesla//media/psi/sync to /
[BGN] Updating file home/isaac/.bash_history from / to
//tesla//media/psi/sync
Failed: Error in setting permissions:
No such file or directory
[chmod(/home/isaac/.bin/vs/git_plugins/.unison.git-do-review.40f3b2519c00f4ebf41528310378e88e.unison.tmp)]
3% 00:05 ETAFailed [home/isaac/.bin/vs/git_plugins/git-do-review]: Error
in setting permissions:
No such file or directory
[chmod(/home/isaac/.bin/vs/git_plugins/.unison.git-do-review.40f3b2519c00f4ebf41528310378e88e.unison.tmp)]
[END] Updating file home/isaac/.bin/vs/git_plugins/git-do-review
[END] Updating file home/isaac/.bash_history
Synchronization incomplete at 18:02:48 (2 items transferred, 0 skipped, 1
failed)
failed: home/isaac/.bin/vs/git_plugins/git-do-review

So... that's odd. This is the errors that I've been seeing before in my
logs.

When I run it again, it's trying to push the changes the other way:

***@bohr:~$ unison

local tesla
props ----> home/isaac/.bin/vs/git_plugins/git-do-review
props ----> home/isaac/.bin/vs/git_plugins/git-do-review

Proceed with propagating updates? [] n

local tesla
props ----> home/isaac/.bin/vs/git_plugins/git-do-review [f]
qTerminated!

So... Maybe that helps.

Is there some setting that I have set that makes competing permissions
changes and file changes cause problems like this? Does it have to do with
the mount option: 'relatime' ?

-Isaac

Post by Isaac Witmer ***@gmail.com [unison-users]
This is hard to debug. Maybe I do need to increase my verbosity or
something.
It happened again, this time with a conflict, so I was able to check it
local tesla
changed <-?-> props home/isaac/.bin/git-do-review [] x
local : changed file modified on 2017-10-25 at 17:07:40 size
2466 rwx--x--x
tesla : changed props modified on 2017-10-25 at 17:11:05 size
2475 rw-------
changed <-?-> props home/isaac/.bin/git-do-review []
"Luckily" there was a conflict, so I noticed it before it propagated
further.
My laptop (the other computer in this set that would have synced this
UNISON 2.48.3 started propagating changes at 16:51:00.32 on 25 Oct 2017
[BGN] Updating file home/isaac/.bin/git-do-review from
//tesla//media/psi/sync to /
[BGN] Updating file home/isaac/.bin/git-do-review from
//tesla//media/psi/sync to /
<-- snip -- some files here -->
No such file or directory [utimes(/home/isaac/.bin/.unison.git-do-review.
40f3b2519c00f4ebf41528310378e88e.unison.tmp)]
[END] Updating file home/isaac/.bin/git-do-review
<-- snip -- some files here -->
UNISON 2.48.3 finished propagating changes at 16:51:00.34 on 25 Oct 2017
Synchronization incomplete at 16:51:00 (4 items transferred, 0 skipped, 1
failed)
failed: home/isaac/.bin/git-do-review
UNISON 2.48.3 started propagating changes at 16:51:02.19 on 25 Oct 2017
[BGN] Copying properties for home/isaac/.bin/git-do-review from / to
//tesla//media/psi/sync
[BGN] Copying properties for home/isaac/.bin/git-do-review from / to
//tesla//media/psi/sync
[END] Copying properties for home/isaac/.bin/git-do-review
[END] Copying properties for home/isaac/.bin/git-do-review
UNISON 2.48.3 finished propagating changes at 16:51:02.19 on 25 Oct 2017
Synchronization complete at 16:51:02 (2 items transferred, 0 skipped, 0
failed)
UNISON 2.48.3 started propagating changes at 17:01:03.99 on 25 Oct 2017
<-- snip -- some files here -->
UNISON 2.48.3 finished propagating changes at 17:01:04.03 on 25 Oct 2017
Synchronization complete at 17:01:04 (6 items transferred, 0 skipped, 0
failed)
UNISON 2.48.3 started propagating changes at 17:11:05.93 on 25 Oct 2017
[BGN] Updating file home/isaac/.bin/git-do-review from
//tesla//media/psi/sync to /
[BGN] Updating file home/isaac/.bin/git-do-review from
//tesla//media/psi/sync to /
<-- snip -- some files here -->
No such file or directory [utimes(/home/isaac/.bin/.unison.git-do-review.
40f3b2519c00f4ebf41528310378e88e.unison.tmp)]
[END] Updating file home/isaac/.bin/git-do-review
<-- snip -- some files here -->
UNISON 2.48.3 finished propagating changes at 17:11:05.96 on 25 Oct 2017
Synchronization incomplete at 17:11:06 (7 items transferred, 0 skipped, 1
failed)
failed: home/isaac/.bin/git-do-review
UNISON 2.48.3 started propagating changes at 17:11:07.81 on 25 Oct 2017
[BGN] Copying properties for home/isaac/.bin/git-do-review from / to
//tesla//media/psi/sync
[BGN] Copying properties for home/isaac/.bin/git-do-review from / to
//tesla//media/psi/sync
[END] Copying properties for home/isaac/.bin/git-do-review
[END] Copying properties for home/isaac/.bin/git-do-review
Is it significant that there's two references to copying end ending the
copy?
I can't figure out why it keeps failing to find the file...
I wonder if that's the reason.
-Isaac
On Thu, Oct 12, 2017 at 12:36 PM, Benoît-Pierre DEMAINE <

Post by Isaac Witmer ***@gmail.com [unison-users]
I use unison to synchronize scripts (and various other things) between
servers, and computers I use.
I've found quite a few times where the execution bit on my scripts seems
to have switched for no apparent reason, other than editing the file in vim.
I think the problem is unison, because often after editing my bash
scripts, I use them immediately, and it's not till the next day I notice
that they're marked -x again.
Does anyone else experience this? Is there any suggestions on how to
prevent it?
-Isaac
- are you editing with the same user as owner of file ? sudo ? su ?
- did you check the full stats of file before and after edition (owner
and properties)
- what is your exact unison sync line ? (regarding user management)
I have found properties were altered when owners had troubles: edit file
on host A; sync it to B; user does not have the same name or ID on both
machines, so, unison will mess owner; new owner may not have permissions to
create X files on this filesystem (see mount options), so unison on B side
will either change owner, or perms of file. On next sync, this is
backported on A.
1: carefully read your full sync logs. Verbose logs always report this
kind of issue.
2: always run TWICE in a row your sync script (all machines once, then,
all machines a second time).
--

Post by Isaac Witmer ***@gmail.com [unison-users]
o_/ DEMAINE Benoît-Pierre (aka DoubleHP) http://benoit.demaine.info/

If computing were an exact science, IT engineers would'nt have work \_o<
"So all that's left, Is the proof that love's not only blind but deaf."
(FAKE TALES OF SAN FRANCISCO, Arctic Monkeys)

['Benjamin C. Pierce' [e-mail] [unison-users]]

This post might be inappropriate. Click to display it.

[[e-mail] [unison-users]]

Post by Isaac Witmer ***@gmail.com [unison-users]
Ok, a bit confused why it shows up twice... continuing anyway...

I've seen this happen when I've inadvertently included the same part of
the file tree twice in the directories to be synchronized.

Post by Isaac Witmer ***@gmail.com [unison-users]
local tesla
props <-?-> changed home/isaac/.bin/vs/git_plugins/git-do-review [] x
local : changed props modified on 2018-01-02 at 15:21:58 size
3211 rw-------
tesla : changed file modified on 2018-01-02 at 15:24:10 size
3012 rwx--x--x
props <-?-> changed home/isaac/.bin/vs/git_plugins/git-do-review [] d
diff -u '/home/isaac/.bin/vs/git_plugins/git-do-review.unison.diff-'
'/home/isaac/.bin/vs/git_plugins/git-do-review'
.... bash code here... it's too ugly to show ...
Looks like there's a permissions difference, and a file size difference.
props <==== changed home/isaac/.bin/vs/git_plugins/git-do-review [] ,
props <==== changed home/isaac/.bin/vs/git_plugins/git-do-review [] ,
changed ----> home/isaac/.bash_history

This is curious, in that the listing of differences noted that the props
were change on one side and the contents were changed on the other
side. But the list of differences to propagate shows only props, and
both times in the same direction.

Dale