Please describe the problem.
The assistant does not sync file permissions so if you set something as executable it won't be set the same on the other repositories.
What steps will reproduce the problem?
On the first host:
$ echo -e '#!/bin/sh\necho "Hello World!"' > testscript
$ chmod ugo+x testscript
$ ./testscript
Hello World!
$ ls -l
total 4
-rwxr-xr-x 1 pedrocr pedrocr 30 May 31 20:00 testscript
And on the second host:
$ ls -l
total 4
-rw-r--r-- 1 pedrocr pedrocr 30 May 31 20:00 testscript
$ ./testscript
bash: ./testscript: Permission denied
What version of git-annex are you using? On what operating system?
$ git annex version
git-annex version: 4.20130516.1
build flags: Assistant Webapp Pairing Testsuite S3 WebDAV Inotify DBus XMPP
local repository version: 4
default repository version: 3
supported repository versions: 3 4
upgrade supported from repository versions: 0 1 2
$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 12.04.2 LTS
Release: 12.04
Codename: precise
More generally, symbolic links cannot have permissions of their own, and git in fact indicates a file is a symlink by setting the tree object's mode to a specific magic number. So there is no git metadata that git-annex can use to track whether a file is supposed to be executable.
Therefore, this will only get fixed when there's some kind of full-fledged metadata storage for git.
Yeah, now i just hit this. kinda annoying.
Couldn't this at least be solved for direct mode repositories?
@Pedro: What Joey is refering to is that git-annex uses sym-links behind the scenes to store even such a small file. (BTW, that can be changed with the large-file config option, IIRC.)
@Joey: Even a "full-fledged metadata storage for git" wouldn't solve this problem since from git's POV it's still just a sym-link without permissions.
Now that git-annex has a proper metadata system now, can this be handled?
Perhaps doing this:
git annex metadata -s __executable 001
could cause git-annex to set the executable bit (on get, fsck etc.) and that be set automatically on git annex add if the file has executable bit set (numbers are a bitmask for which execute bit to set..?).
just ran into this as well, so was looking around. I am afraid that in indirect mode no "proper" solution is possible since for the same content (git-annex key) there could originally be multiple files with different permissions -- e.g. one executable and one not. BUT IMHO even though no proper solution possible, if would indeed be very useful to have it resolved to work for 99% of cases, where such collisions aren't likely and a "union" of executable bit across present files in the repo could be used (so if one is executable, all others with the same content are as well). Since git annex by default inherits/propagates metadata changes across "editions" of the files it would already be handy even if e.g. executable shell scripts gets modified which is kinda a neat side effect