Merge branch 'master' of ssh://git-annex.branchable.com

This commit is contained in:
Joey Hess 2014-05-23 13:01:29 -04:00
commit 2910a85992
8 changed files with 188 additions and 0 deletions

View file

@ -0,0 +1,10 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="24.159.78.125"
subject="comment 1"
date="2014-05-23T14:25:04Z"
content="""
git-annex has always required the remote have git-annex-shell installed in order to store files on it. Nothing has changed in this area.
So, you seem to be very confused about something, but I cannot tell what from this bug report, and I certianly see no evidence of any bug in the information provided so far. You need to install git-annex on your server and then it should work, assuming the server actually has a git-annex repository set up on it.
"""]]

View file

@ -0,0 +1,12 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="24.159.78.125"
subject="comment 4"
date="2014-05-23T14:39:18Z"
content="""
Did a previous version of git-annex work with this particular Android variant before?
Try: `/data/data/ga.androidterm/bin/busybox --install -s /data/data/ga.androidterm/bin`
That should make symlinks, rather than hardlinks. It seems that the policy is somehow denying creation of hard links, but allowing symlinks.
"""]]

View file

@ -0,0 +1,13 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="24.159.78.125"
subject="comment 5"
date="2014-05-23T14:34:34Z"
content="""
My point is that if the filesystem is rejecting all attempts to access it with \"permission denied\", it's hardly surprising that git-annex doesn't work, since nothing works. If running the assistant somehow causes the filesystem to get into this strange broken state, then you have a nice repoducible bug to report on the filesystem, I suppose. I don't see how it could be a bug in git-annex, since it is using only standard posix filesystem system calls, plus inotify.
Based on this, samba/CIFS does not support inotify: <http://stackoverflow.com/questions/8124617/getting-file-create-notifications-for-cifs-mount-in-linux>
Thus, the assistant won't work on it.
If I were you, I'd set up git-annex repositories on local filesystems, and let it take care of the syncronosation, rather than using a networked filesystem.
"""]]

View file

@ -0,0 +1,12 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="24.159.78.125"
subject="comment 2"
date="2014-05-23T14:27:01Z"
content="""
What are you clicking on in the webapp?
What kind of repository did the remote have before it got deleted? Was it a repository encrypted with git-remote-gcrypt?
Show the contents of ~/annex/.git/config on your local system.
"""]]

View file

@ -0,0 +1,107 @@
### Please describe the problem.
When attempting to clone and use a git repository in a subdirectory several levels deep on Windows, I observe symptoms very similar to those described at http://git-annex.branchable.com/direct_mode/#comment-8feee726df4e287dd3751bc77fd1441f. By contrast, when I attempt the same operation in a subdirectory higher up, the operation is successful. Logs of both sessions are given below.
My suspicion is that this has to do with exceeding the maximum path length limitation (MAX_PATH) of 260 characters on Windows, as described here: http://msdn.microsoft.com/en-us/library/aa365247.aspx.
### What steps will reproduce the problem?
See above.
### What version of git-annex are you using? On what operating system?
>git annex version
git-annex version: 5.20140517-gee56d21
build flags: Assistant Webapp Webapp-secure Pairing Testsuite S3 WebDAV DNS Feeds Quvi TDFA CryptoHash
key/value backends: SHA256E SHA1E SHA512E SHA224E SHA384E SKEIN256E SKEIN512E SHA256 SHA1 SHA512 SHA224 SHA384 SKEIN256 SKEIN512 WORM URL
remote types: git gcrypt S3 bup directory rsync web webdav tahoe glacier ddar hook external
local repository version: 5
supported repository version: 5
upgrade supported from repository versions: 2 3 4
>git version
git version 1.9.0.msysgit.0
Operating system: Windows 7 Professional (64-bit), Service Pack 1
### Please provide any additional information below.
[[!format sh """
# If you can, paste a complete transcript of the problem occurring here.
# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
C:\Users\areeves\Documents\Work\MyDirectoryHere\git>git clone ssh://areeves@myserver:/home/work/git/sbv
Cloning into 'sbv'...
remote: Counting objects: 65, done.
remote: Compressing objects: 100% (57/57), done.
remote: Total 65 (delta 26), reused 0 (delta 0)
Receiving objects: 100% (65/65), 9.25 KiB | 0 bytes/s, done.
Resolving deltas: 100% (26/26), done.
Checking connectivity... done.
C:\Users\areeves\Documents\Work\MyDirectoryHere\git>cd sbv
C:\Users\areeves\Documents\Work\MyDirectoryHere\git\sbv>git annex get
Detected a filesystem without fifo support.
Disabling ssh connection caching.
Detected a crippled filesystem.
Enabling direct mode.
git-annex: C:\Users\areeves\Documents\Work\MyDirectoryHere\git\sbv\.git\annex\objects\3de\5f4\SHA256-s765223180--c9e2eebd915b4ade9429b00a7a893df928389b3fb4ab759ea9f00b0e05e18de6\: openTempFile: does not exist (No such file or directory)
C:\Users\areeves\Documents\Work\MyDirectoryHere\git\sbv>git annex direct
commit
On branch master
Your branch is up-to-date with 'origin/master'.
nothing to commit, working directory clean
ok
git-annex: C:\Users\areeves\Documents\Work\MyDirectoryHere\git\sbv\.git\annex\objects\3de\5f4\SHA256-s765223180--c9e2eebd915b4ade9429b00a7a893df928389b3fb4ab759ea9f00b0e05e18de6\: openTempFile: does not exist (No such file or directory)
failed
git-annex: direct: 1 failed
C:\Users\areeves\Documents\Work\MyDirectoryHere\git\sbv>cd c:\temp
c:\temp>git clone ssh://areeves@myserver:/home/work/git/sbv
Cloning into 'sbv'...
remote: Counting objects: 65, done.
remote: Compressing objects: 100% (57/57), done.
remote: Total 65 (delta 26), reused 0 (delta 0)
Receiving objects: 100% (65/65), 9.25 KiB | 0 bytes/s, done.
Resolving deltas: 100% (26/26), done.
Checking connectivity... done.
c:\temp>cd sbv
c:\temp\sbv>git annex direct
Detected a filesystem without fifo support.
Disabling ssh connection caching.
Detected a crippled filesystem.
Enabling direct mode.
(Recording state in git...)
c:\temp\sbv>git annex get
get BigBinaryFile_Data_Package_2012-03-31.tar.bz2.gpg (merging origin/git-annex into git-annex...)
(Recording state in git...)
sent 30 bytes received 765316741 bytes 11011752.10 bytes/sec
total size is 765223180 speedup is 1.00
ok
(Recording state in git...)
c:\temp\sbv>
# End of transcript or log.
"""]]

View file

@ -0,0 +1,16 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="24.159.78.125"
subject="comment 3"
date="2014-05-23T14:57:43Z"
content="""
Yesterday, I made the webapp register ssh remotes it creates.
They then show up in the webapp when run in a repository where that ssh
remote is not enabled.
You can also manually register a ssh remote. First set up the git remote
as usual. Then run `git annex initremote type=git name=foo
location=$url`.
So, this bugs titular issue is fixed, but the issue of it displaying \"unknown\" rather than the remote description is not yet fixed. Will retitle this bug appropriately, and leave open until that gets fixed.
"""]]

View file

@ -0,0 +1,10 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="24.159.78.125"
subject="comment 1"
date="2014-05-23T15:30:23Z"
content="""
I don't recommend moving direct mode repositories between filesystems, because git-annex relies on the inode as one way to detect if files in a direct mode repo have changed. It will notice that all the inode numbers have changed, and fall back to a mode where it only uses mtime.
Anyway, your situation is better handled by initializing a repository on the desktop, and a separate one on the laptop. Then add remotes tying the repos together, and git-annex sync will just do the right thing, including not transferring files that have already been synced to both places.
"""]]

View file

@ -0,0 +1,8 @@
[[!comment format=mdwn
username="jamieson"
ip="71.11.161.246"
subject="Thanks!"
date="2014-05-23T16:11:35Z"
content="""
I'll do it that way, thanks!!
"""]]