mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions

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

Browse source
This commit is contained in:
Joey Hess 2014-06-10 19:23:00 -04:00
commit 201bb931a3
9 changed files with 149 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

8
doc/bugs/Auto-repair_greatly_slows_down_the_machine/comment_11_1c2c3adfbccd2b14a7d1c4618800e735._comment Normal file
View file

@ -0,0 +1,8 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="108.236.230.124"
subject="comment 11"
date="2014-06-10T19:31:38Z"
content="""
Disable consistency checks for the repo in the webapp UI, wait until long enough that you're sure the assistant would be wanting to repair it again if you hadn't disabled that, and run `git annex repair` at the console so I can see what's going on.
"""]]

41
doc/bugs/FAT:_Date_resolution_for_mtime_2s--__62___implications/comment_8_2500e6f9545b916dfa41549140c053fd._comment Normal file
View file

@ -0,0 +1,41 @@
[[!comment format=mdwn
username="martin"
ip="89.183.78.73"
subject="`git-annex add` (called by sync) should do the job and bring the files back home (IMHO)"
date="2014-06-10T15:58:25Z"
content="""
If one does an `git annex sync` these crippled-pseudo-modified-files are *automatically* `git annex add`ed
git annex status
M datei1
M datei5
M datei6
git annex sync
commit add datei1 ok
add datei5 ok
add datei6 ok
To avoid the risk of adding and propagating potentially corrupted content `git-annex add` should
\"simply\" correct the timestamps (adjust to the new even inode values) for files with correct checksum but timestamp
difference of 1s or 1h
With this procedure i would have better sleep with this personal second use case:
repo1: on the computer (direct mode - client)
repo2: on usb stick - (direct mode - client - vfat - music for car)
From time to time mp3 files are transferred to the stick. Then stick
goes to the car and after some days back to the computer to be
synchronized again. Everytime approx. 50% of the recently new added files are
added again (via sync) because of these nonsens timestamps.
So i think, the clean solution is to correct only the timestamps instead
of adding again possibly corrupted files. If we dont do this users adapt to
add files again and again (they need not to be added) and one day they
add corrupted content. Like on windows (tm) you klick OK and OK again and
here you add again and again and one day one add once too much ;-)
Excuse me for this long comment...
P.S. git annex is an ingenious piece of software - thanks a lot for this joey!
"""]]

10
doc/bugs/FAT:_Date_resolution_for_mtime_2s--__62___implications/comment_9_e2dc3ff80bbd66837f00975b16e17126._comment Normal file
View file

@ -0,0 +1,10 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="108.236.230.124"
subject="comment 9"
date="2014-06-10T19:27:55Z"
content="""
> To avoid the risk of adding and propagating potentially corrupted content git-annex add should \"simply\" correct the timestamps (adjust to the new even inode values) for files with correct checksum but timestamp difference of 1s or 1h
Since git-annex add already does that in this case, I think what you're actually suggesting is that, if the timestamp has a 1s or 1h diff, but the checksum has changed, git-annex add should refuse to add the files, on the grounds that it appears to be corrupt. Which obviously fails badly in at least the 1h case, because someone could add a file, then wait 1 hour and git-annex add a modified version.
"""]]

23
doc/forum/Need_to_recover_unused_files_because_of_bad_sync__63__/comment_4_8e079e92929dcfdf19f6adec16f800e5._comment Normal file
View file

@ -0,0 +1,23 @@
[[!comment format=mdwn
username="feulif"
ip="151.27.145.89"
subject="comment 4"
date="2014-06-10T18:43:34Z"
content="""
Here is the log of the \"bad\" commit:
commit 38e0e1ef009b820f008b46f53c24d9835ca0f9a6
Author: me <me@myself.com>
Date: Wed Jun 4 00:04:37 2014 +0200
git-annex automatic sync
folder/subfolder1/subfolder2/photo.jpg | 1 +
[...]
[...]
[...]
folder/subfolder1/subfolderN/video.MOV | 1 +
2266 files changed, 2266 insertions(+)
I stopped (ctrl-c) when it was adding the video.
"""]]

9
doc/todo/Bittorrent-like_features/comment_6_489505da4143fb1c2bf21e7af695cdef._comment Normal file
View file

@ -0,0 +1,9 @@
[[!comment format=mdwn
username="https://www.google.com/accounts/o8/id?id=AItOawmHp5oVW8Z9v_vHs5FRtlYj80TYMQWVTS0"
nickname="dhead"
subject="comment 6"
date="2014-06-10T02:18:43Z"
content="""
What about Syncthing protocol ?
https://github.com/calmh/syncthing/blob/master/protocol/PROTOCOL.md
"""]]

23
doc/todo/windows_support/comment_18_3a408492107ca6f120b631ce8c41faef._comment Normal file
View file

@ -0,0 +1,23 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="108.236.230.124"
subject="nssm notes"
date="2014-06-10T18:16:00Z"
content="""
* Have to install and run nssm as an administrator. (It may be possible to get it to run as a non-administrator user if the admin sets it up. I haven't succeeded.)
* `nssm install git-annex`
* Set path to git-annex, and set Arguments to: `assistant --autostart`
* In Exit tab, change Restart to \"No action\"
* In Process tab, uncheck \"Console window\"
* Repositories to start up have to be listed in `C:\Documents and Settings\LocalService\.config\git-annex\autostart`
(rather than the normal user home directory)
After all that it works! Even opening git-annex webapp from the menu avoids the console window (it appears briefly but then goes away).
Most of this setup could be boiled down to a command line invocation, which git-annex could do at install time. However, it would still need to be run by the admin. Luckily the git-annex installation process already only works as admin (and I guess I could close the bug about that if it gets a legitimate reason to need admin..)
Some changes in git-annex would improve this.
* Maybe have a way to specify the user that git-annex is running on behalf of, and look in that user's home directory, rather than LocalService. (Other parts of the webapp UI, like adding a new repository, also use LocalService as the home directory, which is confusing).
* Starting the webapp for the first time to create a repository still opens a console window, so find a workaround for this.
"""]]

8
doc/todo/windows_support/comment_19_c6cbc8fe9218f90c661cd1026658c939._comment Normal file
View file

@ -0,0 +1,8 @@
[[!comment format=mdwn
username="https://www.google.com/accounts/o8/id?id=AItOawm9ocq1Kb0WL-cz-LPpvd2Xm-q8tIQvqXA"
nickname="Dominik"
subject="comment 19"
date="2014-06-10T18:24:22Z"
content="""
That sounds great! I'll try it out on windows 8 aswell once i get around to it.
"""]]

17
doc/todo/windows_support/comment_20_ca245781a37db5546da3f7204adbeebb._comment Normal file
View file

@ -0,0 +1,17 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="108.236.230.124"
subject="comment 20"
date="2014-06-10T19:11:57Z"
content="""
This seems pretty close to a command line to install the service with nssm.
<pre>
nssm install git-annex 'C:\Program Files\Git\cmd\git-annex.exe' assistant --autostart
nssm set git-annex AppExit 0 Ignore
nssm set git-annex AppExit 1 Ignore
nssm set git-annex AppDirectory C:\
nssm set git-annex AppNoConsole 1
nssm start git-annex
</pre>
"""]]

10
doc/videos/git-annex_assistant_lan/comment_2_d4e3122da9c9e27fbe872e09fcde762b._comment Normal file
View file

@ -0,0 +1,10 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="108.236.230.124"
subject="magic"
date="2014-06-10T16:13:35Z"
content="""
In the screencast, I run git-annex after unpacking it, and this lets it register where it's installed at.
So it is important to run git-annex after you unpack it.
"""]]