From d7ec1435ef80d426b4e4e830d56f74c23288d689 Mon Sep 17 00:00:00 2001 From: "https://www.google.com/accounts/o8/id?id=AItOawkJafmCf-sg9_OM0pynFYM3AO4WCgJiaMI" Date: Sun, 13 Oct 2013 21:43:56 +0000 Subject: --- doc/forum/cross_platform_permissions_woes.mdwn | 35 ++++++++++++++++++++++++++ 1 file changed, 35 insertions(+) create mode 100644 doc/forum/cross_platform_permissions_woes.mdwn diff --git a/doc/forum/cross_platform_permissions_woes.mdwn b/doc/forum/cross_platform_permissions_woes.mdwn new file mode 100644 index 000000000..882b1dc3e --- /dev/null +++ b/doc/forum/cross_platform_permissions_woes.mdwn @@ -0,0 +1,35 @@ +a little introduction: +i am forced to use windows on my work laptop and workstation, also my wife needs windows. +my "servers" would be linux, i am actually using fedora and i upgraded from fc17 since i was not able to get a recent version of git annex to compile there. + +what happens, is that once i try to copy from the windows machine where the file is to the linux through ssh+rsync, i receive this error - as long as the user owning the linux repository isn't root: + + c:\locale>git annex copy --to linux myfile + copy bella (checking linux...) (to linux...) + rsync: failed to open "/linux/annex/tmp/SHA256E-s10--937a89b559820f8658892" + myfile + 10 100% 0.00kB/s 0:00:00 (xfer#1, to-check=0/1) + rsync error: syntax or usage error (code 1) at /home/lapo/package/rsync-3.0.9-1/src/rsyn + total size is 10 speedup is 0.09 + failed + git-annex: copy: 1 failed + +the file in tmp has no permissions at all: + + me@linux annex]$ ls -lart tmp/SHA256E-s10--937a89b559820f86588921ef3eb12c13074d +078b62ef205bb597bf2e895408c3 + ----------. 1 me me 10 Oct 13 22:50 tmp/SHA256Es10--937a89b559820f86588921ef3eb12c13074d078b62ef205bb597bf2e895408c3 + +(just consider this if the above makes any sense:) in another case (i cannot reproduce it now, possibly due to having upgraded git annex from some 2012 release), it happened that a failed download via copy/move from linux to windows (failed for permissions) would not be recorded as failed (on windows side), causing files to possibly be killed at the first subsequent drop command. + +my question is: are these 0-permissions on tmp files a bug or just due to some ignorance i did put in setting up the git/annex repo ? is a git/annex repo to be run solely as root/sudoer ? or shall i take any other step in configuring it ? + +technicalities: + +"client": windows version: + + git-annex version: 4.20131002-gf25991c + +"server": linux version: + + git-annex version: 3.20130207 -- cgit v1.2.3 From c8be515f834183ea13084ef06056c39b9973f2fd Mon Sep 17 00:00:00 2001 From: "https://www.google.com/accounts/o8/id?id=AItOawkJafmCf-sg9_OM0pynFYM3AO4WCgJiaMI" Date: Sun, 13 Oct 2013 21:45:37 +0000 Subject: --- doc/forum/cross_platform_permissions_woes.mdwn | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/doc/forum/cross_platform_permissions_woes.mdwn b/doc/forum/cross_platform_permissions_woes.mdwn index 882b1dc3e..d094070f5 100644 --- a/doc/forum/cross_platform_permissions_woes.mdwn +++ b/doc/forum/cross_platform_permissions_woes.mdwn @@ -16,8 +16,7 @@ what happens, is that once i try to copy from the windows machine where the file the file in tmp has no permissions at all: - me@linux annex]$ ls -lart tmp/SHA256E-s10--937a89b559820f86588921ef3eb12c13074d -078b62ef205bb597bf2e895408c3 + me@linux annex]$ ls -lart tmp/SHA256E-s10--937a89b559820f86588921ef3eb12c13074d078b62ef205bb597bf2e895408c3 ----------. 1 me me 10 Oct 13 22:50 tmp/SHA256Es10--937a89b559820f86588921ef3eb12c13074d078b62ef205bb597bf2e895408c3 (just consider this if the above makes any sense:) in another case (i cannot reproduce it now, possibly due to having upgraded git annex from some 2012 release), it happened that a failed download via copy/move from linux to windows (failed for permissions) would not be recorded as failed (on windows side), causing files to possibly be killed at the first subsequent drop command. -- cgit v1.2.3 From 7f05f149f7b4d138c401d05ee1a57fd6df264609 Mon Sep 17 00:00:00 2001 From: "https://www.google.com/accounts/o8/id?id=AItOawkJafmCf-sg9_OM0pynFYM3AO4WCgJiaMI" Date: Sun, 13 Oct 2013 21:47:38 +0000 Subject: --- doc/forum/cross_platform_permissions_woes.mdwn | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/forum/cross_platform_permissions_woes.mdwn b/doc/forum/cross_platform_permissions_woes.mdwn index d094070f5..485bc1215 100644 --- a/doc/forum/cross_platform_permissions_woes.mdwn +++ b/doc/forum/cross_platform_permissions_woes.mdwn @@ -5,7 +5,7 @@ my "servers" would be linux, i am actually using fedora and i upgraded from fc17 what happens, is that once i try to copy from the windows machine where the file is to the linux through ssh+rsync, i receive this error - as long as the user owning the linux repository isn't root: c:\locale>git annex copy --to linux myfile - copy bella (checking linux...) (to linux...) + copy myfile (checking linux...) (to linux...) rsync: failed to open "/linux/annex/tmp/SHA256E-s10--937a89b559820f8658892" myfile 10 100% 0.00kB/s 0:00:00 (xfer#1, to-check=0/1) -- cgit v1.2.3 From 1de5ea32d80ab47b4a0c7b5067e9477f6825580a Mon Sep 17 00:00:00 2001 From: "https://www.google.com/accounts/o8/id?id=AItOawkJafmCf-sg9_OM0pynFYM3AO4WCgJiaMI" Date: Sun, 13 Oct 2013 21:57:30 +0000 Subject: --- doc/forum/cross_platform_permissions_woes.mdwn | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/forum/cross_platform_permissions_woes.mdwn b/doc/forum/cross_platform_permissions_woes.mdwn index 485bc1215..0cf62bab0 100644 --- a/doc/forum/cross_platform_permissions_woes.mdwn +++ b/doc/forum/cross_platform_permissions_woes.mdwn @@ -19,7 +19,7 @@ the file in tmp has no permissions at all: me@linux annex]$ ls -lart tmp/SHA256E-s10--937a89b559820f86588921ef3eb12c13074d078b62ef205bb597bf2e895408c3 ----------. 1 me me 10 Oct 13 22:50 tmp/SHA256Es10--937a89b559820f86588921ef3eb12c13074d078b62ef205bb597bf2e895408c3 -(just consider this if the above makes any sense:) in another case (i cannot reproduce it now, possibly due to having upgraded git annex from some 2012 release), it happened that a failed download via copy/move from linux to windows (failed for permissions) would not be recorded as failed (on windows side), causing files to possibly be killed at the first subsequent drop command. +(just consider the following if the above makes any sense:) in another case (i cannot reproduce it now, possibly due to having upgraded git annex from some 2012 release), it happened that a failed download via copy/move from linux to windows (failed for permissions) would not be recorded as failed (on windows side), causing files to possibly be killed at the first subsequent drop command. my question is: are these 0-permissions on tmp files a bug or just due to some ignorance i did put in setting up the git/annex repo ? is a git/annex repo to be run solely as root/sudoer ? or shall i take any other step in configuring it ? -- cgit v1.2.3 From 86d5b789fb15f22db2ad35a55620230dbb226915 Mon Sep 17 00:00:00 2001 From: RaspberryPie Date: Sun, 13 Oct 2013 22:14:05 +0000 Subject: Added a comment --- ...ent_7_5fd39168c9e1bf43909ee0ab3c75c40c._comment | 35 ++++++++++++++++++++++ 1 file changed, 35 insertions(+) create mode 100644 doc/forum/git-annex:_status:_1_failed/comment_7_5fd39168c9e1bf43909ee0ab3c75c40c._comment diff --git a/doc/forum/git-annex:_status:_1_failed/comment_7_5fd39168c9e1bf43909ee0ab3c75c40c._comment b/doc/forum/git-annex:_status:_1_failed/comment_7_5fd39168c9e1bf43909ee0ab3c75c40c._comment new file mode 100644 index 000000000..54f87581c --- /dev/null +++ b/doc/forum/git-annex:_status:_1_failed/comment_7_5fd39168c9e1bf43909ee0ab3c75c40c._comment @@ -0,0 +1,35 @@ +[[!comment format=mdwn + username="RaspberryPie" + ip="37.130.227.133" + subject="comment 7" + date="2013-10-13T22:14:05Z" + content=""" +Yes, I run the assistant in the background. The error came up after I ran + + git init + git annex init + git annex direct + git annex assistant + +in a directory containing a lot of files (around 80G). Right away, `git annex status` gave me the error below. The file name in question never changed during the process of adding files and hasn't changed after all files have been added. + +Here's the complete command line output: + + $ git annex status + supported backends: SHA256E SHA1E SHA512E SHA224E SHA384E SHA256 SHA1 SHA512 SHA224 SHA384 WORM URL + supported remote types: git gcrypt S3 bup directory rsync web glacier hook + repository mode: direct + trusted repositories: 0 + semitrusted repositories: 2 + 00000000-0000-0000-0000-000000000001 -- web + c1bb8eb9-fb0c-4bac-b0df-37df25b2d1e7 -- here + untrusted repositories: 0 + transfers in progress: none + available local disk space: 1.74 terabytes (+10 gigabytes reserved) + + git-annex: /storage/media/.git/annex/tmp/problematic_file--: getFileStatus: does not exist (No such file or directory) + failed + git-annex: status: 1 failed + + +"""]] -- cgit v1.2.3 From a21d5aae341691ad0b29cadfbc4ba93a27bb4ae8 Mon Sep 17 00:00:00 2001 From: GLITTAH Date: Sun, 13 Oct 2013 23:07:25 +0000 Subject: --- ...hlist:___39__get__39___queue_and_schedule..mdwn | 30 ++++++++++++++++++++++ 1 file changed, 30 insertions(+) create mode 100644 doc/todo/wishlist:___39__get__39___queue_and_schedule..mdwn diff --git a/doc/todo/wishlist:___39__get__39___queue_and_schedule..mdwn b/doc/todo/wishlist:___39__get__39___queue_and_schedule..mdwn new file mode 100644 index 000000000..8919bae3f --- /dev/null +++ b/doc/todo/wishlist:___39__get__39___queue_and_schedule..mdwn @@ -0,0 +1,30 @@ +During the campaign adding a chunking feature to obscure filesize for encrypted files was added to the roadmap. But there is still one potentially valuable set* of data that git-annex can help obscure: when you access your remotes. + +This data can be used to determine when a user is actively using a remote, but if a remote is always accessed at the same time that data becomes less useful. Somebody could still monitor total traffic over a long period and figure out that a remote was more active in a given week or month, but scheduling reduces the resolution of your access times and their data. Maybe this isn't the most important feature to add, but it would be nice to have, and could possibly be built on top of the existing git-annex scheduler. It could work by queuing inter-remote transactions ('get', 'copy', 'sync', etc.), so that jobs start at the same time every day, or even the same time and day every week. + +Possible syntax examples: +###Setting up the schedule: +git annex queue schedule Monday:1730 (starts every monday at 5:30PM) + +git annex queue schedule 1400 (starts every day at 2PM) + +###Queuing git-annex commands: +git annex queue prepend sync (pretends 'sync' to the very front of the queue) + +git annex queue append get file.ISO (appends to queue file.ISO for retrieval from a repo) + +###Viewing/editing queue: +git annex queue view (view the current queue, jobs displayed with corresponding numbers) + +git annex queue rm 20 (removes job 20 from queue) + + +\*The four I can think of are: + +* File contents (solved by crypto) + +* File size (solved on the remote by chunking, but total traffic usage can't be helped) + +* User IP/Remote IP (solved by VPN - outside scope of git-annex, unless someone writes a plugin) + +* Access times (obscured by a queue and scheduling) -- cgit v1.2.3 From c2ee2adda3ade48705f33b09a884a632d1e2b1ec Mon Sep 17 00:00:00 2001 From: bla Date: Mon, 14 Oct 2013 06:13:19 +0000 Subject: --- ...er_git_annex_add_on_vfat__47__sdcard__47__android.mdwn | 15 ++++++++++++--- 1 file changed, 12 insertions(+), 3 deletions(-) diff --git a/doc/bugs/Git_annex_hangs_after_git_annex_add_on_vfat__47__sdcard__47__android.mdwn b/doc/bugs/Git_annex_hangs_after_git_annex_add_on_vfat__47__sdcard__47__android.mdwn index adff3e57f..62e186550 100644 --- a/doc/bugs/Git_annex_hangs_after_git_annex_add_on_vfat__47__sdcard__47__android.mdwn +++ b/doc/bugs/Git_annex_hangs_after_git_annex_add_on_vfat__47__sdcard__47__android.mdwn @@ -1,8 +1,6 @@ ### Please describe the problem. git add hangs. Maybe because of encrypted sdcard? -/dev/block/dm-2 /mnt/sdcard vfat rw,dirsync,nosuid,nodev,noexec,relatime,uid=1000,gid=1015,fmask=0702,dmask=0702,allow_utime=0020,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro 0 0 -tmpfs /mnt/sdcard/.android_secure tmpfs ro,relatime,size=0k,mode=000 0 0 @@ -31,7 +29,8 @@ tmpfs /mnt/sdcard/.android_secure tmpfs ro,relatime,size=0k,mode=000 0 0 [2013-10-13 22:05:17 CEST] chat: git ["--git-dir=/mnt/sdcard/annex/.git","--work-tree=/mnt/sdcard/annex","cat-file","--batch"] add lala [2013-10-13 22:05:17 CEST] chat: git ["--git-dir=/mnt/sdcard/annex/.git","--work-tree=/mnt/sdcard/annex","check-attr","-z","--stdin","annex.backend","annex.numcopies","--"] ** HANGS ** - + + The same will happen when just running and asking assistant to create annex for camera. @@ -245,6 +244,12 @@ lsof | grep git: 9879 /data/data/ga.androidterm/lib/lib.git.so pipe:[1177784] +vfat/sdcard entry: + /dev/block/dm-2 /mnt/sdcard vfat rw,dirsync,nosuid,nodev,noexec,relatime,uid=1000,gid=1015,fmask=0702,dmask=0702, \ + allow_utime=0020,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro 0 0 + tmpfs /mnt/sdcard/.android_secure tmpfs ro,relatime,size=0k,mode=000 0 0 + + ### What version of git-annex are you using? On what operating system? Version from git annex version: @@ -254,6 +259,10 @@ I tried both daily build and most recent 'stable' with the same effect. Android 4.0.3 (Htc One V) +The same happens on my another android device; Samsung tablet with... also 4.0.3. +Tried to gather strace information on git, but couldn't. If anything more is necessary, +please let me know. + ### Please provide any additional information below. [[!format sh """ -- cgit v1.2.3 From 797ce66ad572fc3808409f7bc2776e5c4ee8bda0 Mon Sep 17 00:00:00 2001 From: bla Date: Mon, 14 Oct 2013 06:19:37 +0000 Subject: --- ...nnex_hangs_after_git_annex_add_on_vfat__47__sdcard__47__android.mdwn | 2 ++ 1 file changed, 2 insertions(+) diff --git a/doc/bugs/Git_annex_hangs_after_git_annex_add_on_vfat__47__sdcard__47__android.mdwn b/doc/bugs/Git_annex_hangs_after_git_annex_add_on_vfat__47__sdcard__47__android.mdwn index 62e186550..23269d9d9 100644 --- a/doc/bugs/Git_annex_hangs_after_git_annex_add_on_vfat__47__sdcard__47__android.mdwn +++ b/doc/bugs/Git_annex_hangs_after_git_annex_add_on_vfat__47__sdcard__47__android.mdwn @@ -263,6 +263,8 @@ The same happens on my another android device; Samsung tablet with... also 4.0.3 Tried to gather strace information on git, but couldn't. If anything more is necessary, please let me know. +The same happens when I git annex add in /data/data/ga.androidterm/anntmp - so it's not sdcard nor vfat. + ### Please provide any additional information below. [[!format sh """ -- cgit v1.2.3 From 62252ac13e2c8f2afbf58f2e1658358dd6a3c000 Mon Sep 17 00:00:00 2001 From: "https://www.google.com/accounts/o8/id?id=AItOawlhE8Xar6m4x3JSILXdm-Y5KhwHTH5qzKQ" Date: Mon, 14 Oct 2013 14:43:11 +0000 Subject: Added a comment: +1 --- .../comment_1_304431bb62b5b8a64edc37a11bbaff59._comment | 8 ++++++++ 1 file changed, 8 insertions(+) create mode 100644 doc/todo/wishlist:_annex.largefiles_support_for_mimetypes/comment_1_304431bb62b5b8a64edc37a11bbaff59._comment diff --git a/doc/todo/wishlist:_annex.largefiles_support_for_mimetypes/comment_1_304431bb62b5b8a64edc37a11bbaff59._comment b/doc/todo/wishlist:_annex.largefiles_support_for_mimetypes/comment_1_304431bb62b5b8a64edc37a11bbaff59._comment new file mode 100644 index 000000000..b06008475 --- /dev/null +++ b/doc/todo/wishlist:_annex.largefiles_support_for_mimetypes/comment_1_304431bb62b5b8a64edc37a11bbaff59._comment @@ -0,0 +1,8 @@ +[[!comment format=mdwn + username="https://www.google.com/accounts/o8/id?id=AItOawlhE8Xar6m4x3JSILXdm-Y5KhwHTH5qzKQ" + nickname="bruno" + subject="+1" + date="2013-10-14T14:43:11Z" + content=""" +Big +1 for this feature: this would really help configuring annex.largefiles +"""]] -- cgit v1.2.3 From 62feb876b1d9d7d9c40e763a85b295450f45dd37 Mon Sep 17 00:00:00 2001 From: "http://joeyh.name/" Date: Mon, 14 Oct 2013 16:18:03 +0000 Subject: Added a comment --- .../comment_7_73e8a5696709f8154e63693ba5e569c3._comment | 10 ++++++++++ 1 file changed, 10 insertions(+) create mode 100644 doc/bugs/Assistant_stalls_when_adding__47__creating_repo_on_ArchLinux/comment_7_73e8a5696709f8154e63693ba5e569c3._comment diff --git a/doc/bugs/Assistant_stalls_when_adding__47__creating_repo_on_ArchLinux/comment_7_73e8a5696709f8154e63693ba5e569c3._comment b/doc/bugs/Assistant_stalls_when_adding__47__creating_repo_on_ArchLinux/comment_7_73e8a5696709f8154e63693ba5e569c3._comment new file mode 100644 index 000000000..b6df85923 --- /dev/null +++ b/doc/bugs/Assistant_stalls_when_adding__47__creating_repo_on_ArchLinux/comment_7_73e8a5696709f8154e63693ba5e569c3._comment @@ -0,0 +1,10 @@ +[[!comment format=mdwn + username="http://joeyh.name/" + ip="64.134.31.139" + subject="comment 7" + date="2013-10-14T16:18:01Z" + content=""" +I just ran into this problem myself. Some investigating shows it is a problem with Yesod's XSRF token. Apparently yesod is not seeing the _token, or is seeing one it does not like. However, I verified in chromium inspector that the form post was including the token with the same value used on the page. Also, it would intermittently accept the form, if I kept posting it over and over again. + +It seems this must be a bug in yesod, or on something with how I'm using yesod, or possibly in deeper layers like WAI not seeing the form post include the token, but I have not been able to figure out what. As a workaround, since git-annex webapp does its own authentication and only listens to localhost, and so does not actually need XSRF protection, I am going to change it to bypass that. +"""]] -- cgit v1.2.3