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-11 19:07:26 -04:00
commit 3ee75d8738
9 changed files with 131 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

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

@ -0,0 +1,10 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="108.236.230.124"
subject="comment 14"
date="2014-06-11T18:59:49Z"
content="""
Opened a separate bug for [[Windows_file_timestamp_timezone_madness]].
Fixed FAT issue on Linux as discussed in my previous comment.
"""]]

8
doc/bugs/On_Ubuntu_14.04_assistant_fails_to_create_new_setup/comment_4_62be3dd4092b15cdf85cf9a231b2863a._comment Normal file
View file

@ -0,0 +1,8 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="108.236.230.124"
subject="comment 4"
date="2014-06-11T20:09:14Z"
content="""
What happens if you run `git-annex assistant --autostart` ?
"""]]

12
doc/bugs/Windows_file_timestamp_timezone_madness/comment_1_9db59ab2242186a23a47337a1597f4e2._comment Normal file
View file

@ -0,0 +1,12 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="108.236.230.124"
subject="comment 1"
date="2014-06-11T19:09:17Z"
content="""
Rather than getting the timezone, another approach might be to look at the inode sentinal file. Its timestamp will also appear to have changed. If the delta is exactly some number of hours, and the inode sential's other data is unchanged, a Windows-specific hack could apply that same delta to all inode cache timestamps.
Except, time zones are not all actually on hour boundaries. Some are half hours, some may be 15 minutes, and next week some crazy country might legislate a 3 minute delta for all I know.
Well, could just say if the inode sentinal's mtime has changed at all (delta < 3600 seconds), and it's otherwise unchanged, and we're on windows, assume this is a time zone change. When would that fail? Only if the repository is copied to someplace, and the mtime is not preserved.
"""]]

26
doc/bugs/Windows_file_timestamp_timezone_madness/comment_2_a6a3871747306913b69abcd73d13305e._comment Normal file
View file

@ -0,0 +1,26 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="108.236.230.124"
subject="comment 2"
date="2014-06-11T19:51:15Z"
content="""
Note that multiple time zone changes complicate this. I think that means that the delta can't be simply applied when comparing inode caches. Instead, probably it needs to be applied when generating inode caches.
A scenario:
1. Time zone is at +1h when the inode sential is written.
2. Time zone changes to +2h
3. File F is added (with a current timestamp of T)
4. Time zone changes to +5h
I am a little confused by which way windows moves the timestamps when the time zone changes. Let's assume I might get the sign wrong.
Let F's timestamp after step 4, F4 = T+-3h.
Let the delta after step 4, D4 = +-4h
And, let the delta after step 2, D2 = +-1h
If step 3 writes the current timestamp to the inode cache, then the cache still has T in it after step 4. F4+D4 /= T (T +-3h +-4h /= T). So comparison doesn't work.
If instead the current delta is applied when generating inode caches (both for storing on disk, and for immediate comparison), then the inode cache will have T+D2 in it. Then after step 4, generating a new inode cache for F will yield F4+D4. So, does F4+D4 == T+D2? T +-3h +-4h == T +-1h YES!
"""]]

20
doc/bugs/Windows_file_timestamp_timezone_madness/comment_3_7fe149bedb8ceab75953996ac8e20f0f._comment Normal file
View file

@ -0,0 +1,20 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="108.236.230.124"
subject="comment 3"
date="2014-06-11T22:11:38Z"
content="""
I have implemented this on the loststamp git branch. It seems to work!
However, it has a big problem:
If the timezone changes while the assistant (or a long-running command)
runs, it won't notice, since it only checks the inode cache once, and
so will use the old delta for all new inode caches it generates for new
files it's added. Which will result in them seeming changed the next time
it runs.
So, it would be really nice to be able to check the actual timezone instead.
But I suppose I can make the assistant poll the inode cache file, or check
it when adding a new file, or something like that. Bleagh.
"""]]

10
doc/bugs/Windows_file_timestamp_timezone_madness/comment_4_c9e8c9997b7c3a82c14fc34af319382d._comment Normal file
View file

@ -0,0 +1,10 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="108.236.230.124"
subject="comment 4"
date="2014-06-11T22:54:48Z"
content="""
Getting the actual time zone on windows works better if you unset TZ first.
But, a haskell program that polls the time zone fails to notice when it's changed. It only notices after being restarted. I have contacted the time library maintainer about this.
"""]]

23
doc/bugs/Windows_file_timestamp_timezone_madness/comment_5_0739426403f5bf9954acbc86ca0d11ea._comment Normal file
View file

@ -0,0 +1,23 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="108.236.230.124"
subject="comment 5"
date="2014-06-11T23:02:28Z"
content="""
I've developed a fix for the time library. This patch has been sent to the author, hopefully it will get applied and then I can use getCurrentTImeZone. Note that git-annex would need to unset TZ first, which might be hard on windows.
<pre>
diff --git a/cbits/HsTime.c b/cbits/HsTime.c
index cfafb27..86ca92a 100644
--- a/cbits/HsTime.c
+++ b/cbits/HsTime.c
@@ -8,6 +8,7 @@ long int get_current_timezone_seconds (time_t t,int* pdst,char const* * pname)
tzset();
struct tm* ptm = localtime_r(&t,&tmd);
#else
+ tzset();
struct tm* ptm = localtime(&t);
#endif
if (ptm)
</pre>
"""]]

14
doc/bugs/git-annex:_createSession:_permission_denied___40__Operation_not_permitted__41__/comment_4_975d2631faa17d257a6fce40e24a6e3b._comment Normal file
View file

@ -0,0 +1,14 @@
[[!comment format=mdwn
username="https://www.google.com/accounts/o8/id?id=AItOawk7iPiqWr3BVPLWEDvJhSSvcOqheLEbLNo"
nickname="Dirk"
subject="comment 4"
date="2014-06-11T19:47:35Z"
content="""
For me the autobuilt tarball works. Go to this page: http://git-annex.branchable.com/install/Linux_standalone/. Right before the comments start is a list of the different autobuilt tar balls.
I assume that this fix will appear in the regular tarballs with the next release.
Dirk
"""]]

8
doc/videos/git-annex_assistant_lan/comment_4_c710e27db41311b157d8caaafc32dc7e._comment Normal file
View file

@ -0,0 +1,8 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="108.236.230.124"
subject="comment 4"
date="2014-06-11T19:56:49Z"
content="""
Running git-annex will also register it on OSX. The registration just consists of making a ~/.ssh/git-annex-shell that runs the real git-annex-shell. The assistant detects when it needs to use that wrapper when setting up a repository.
"""]]