From 1d4497b35826e1cab3c151d9d590ce1cc5af234d Mon Sep 17 00:00:00 2001 From: "https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4" Date: Sat, 24 Sep 2016 02:43:22 +0000 Subject: Added a comment: +may be "byte-target" field? ;) --- .../comment_6_25f9cd3d341c60a059f462a34c89d1d6._comment | 8 ++++++++ 1 file changed, 8 insertions(+) create mode 100644 doc/todo/interface_to_the___34__progress__34___of_annex_operations/comment_6_25f9cd3d341c60a059f462a34c89d1d6._comment diff --git a/doc/todo/interface_to_the___34__progress__34___of_annex_operations/comment_6_25f9cd3d341c60a059f462a34c89d1d6._comment b/doc/todo/interface_to_the___34__progress__34___of_annex_operations/comment_6_25f9cd3d341c60a059f462a34c89d1d6._comment new file mode 100644 index 000000000..5b1134be8 --- /dev/null +++ b/doc/todo/interface_to_the___34__progress__34___of_annex_operations/comment_6_25f9cd3d341c60a059f462a34c89d1d6._comment @@ -0,0 +1,8 @@ +[[!comment format=mdwn + username="https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4" + subject="+may be "byte-target" field? ;)" + date="2016-09-24T02:43:21Z" + content=""" +THANK YOU for implementing this feature -- we will make use of it soon. +But so we don't do reverse estimation from \"byte-progress\" and \"percent-progress\", and didn't have to get it from a key (which might not have it e.g. in case of URL relaxed backend) -- could you just include in each record the \"byte-target\" (if known) or something like that? ;) thanks in advance! +"""]] -- cgit v1.2.3 From 16f51381843b8f38e864d6643bd1c25a12307b20 Mon Sep 17 00:00:00 2001 From: PaulK Date: Sat, 24 Sep 2016 04:16:52 +0000 Subject: Added a comment --- .../comment_6_8e05f8769870b3f1aec77fca06f37284._comment | 7 +++++++ 1 file changed, 7 insertions(+) create mode 100644 doc/bugs/git-annex_won__39__t_execute_on_WD_My_Cloud_NAS/comment_6_8e05f8769870b3f1aec77fca06f37284._comment diff --git a/doc/bugs/git-annex_won__39__t_execute_on_WD_My_Cloud_NAS/comment_6_8e05f8769870b3f1aec77fca06f37284._comment b/doc/bugs/git-annex_won__39__t_execute_on_WD_My_Cloud_NAS/comment_6_8e05f8769870b3f1aec77fca06f37284._comment new file mode 100644 index 000000000..d56e90c83 --- /dev/null +++ b/doc/bugs/git-annex_won__39__t_execute_on_WD_My_Cloud_NAS/comment_6_8e05f8769870b3f1aec77fca06f37284._comment @@ -0,0 +1,7 @@ +[[!comment format=mdwn + username="PaulK" + subject="comment 6" + date="2016-09-24T04:16:51Z" + content=""" +Nope, no difference. Same \"ELF load command alignment not page-aligned\" errors as before. +"""]] -- cgit v1.2.3 From 200926455ef5bf9d60be17870c340784aeb8b26e Mon Sep 17 00:00:00 2001 From: erics Date: Sun, 25 Sep 2016 00:33:57 +0000 Subject: Added a comment --- .../comment_4_cb92e81c1ea00ca72f9a5ee729d627f4._comment | 11 +++++++++++ 1 file changed, 11 insertions(+) create mode 100644 doc/todo/transitive_transfers/comment_4_cb92e81c1ea00ca72f9a5ee729d627f4._comment diff --git a/doc/todo/transitive_transfers/comment_4_cb92e81c1ea00ca72f9a5ee729d627f4._comment b/doc/todo/transitive_transfers/comment_4_cb92e81c1ea00ca72f9a5ee729d627f4._comment new file mode 100644 index 000000000..bf6887ec5 --- /dev/null +++ b/doc/todo/transitive_transfers/comment_4_cb92e81c1ea00ca72f9a5ee729d627f4._comment @@ -0,0 +1,11 @@ +[[!comment format=mdwn + username="erics" + subject="comment 4" + date="2016-09-25T00:33:56Z" + content=""" +> And there is a complication with running [`git annex copy --from --to`] at the same time as eg `git annex get` of the same file. It would be surprising for get to succeed (because copy has already temporarily downloaded the file) and then have the file later get dropped. + +A solution to this subproblem would transparently fall out of a facility for [logically dropping files](http://git-annex.branchable.com/todo/wishlist__58_____96__git_annex_drop_--relaxed__96__/#comment-9672d46a18a381971dd818cde6efbc33), which was briefly talked about a long time ago. Just mark the file as *logically dropped*. If the user `git annex get`s it while the copy-out is in progress, its status will change to \"present\", so *copy* will know not to physically delete it. + +(Of course there are race conditions involved, but I presume/hope that they're no worse than git-annex already has to deal with.) +"""]] -- cgit v1.2.3 From e46e0c62af12ce0ed76da4d0ba3941680055de9d Mon Sep 17 00:00:00 2001 From: erics Date: Sun, 25 Sep 2016 02:28:19 +0000 Subject: --- ...f_backward_compatibility_seems_like_a_showstopper.mdwn | 15 +++++++++++++++ 1 file changed, 15 insertions(+) create mode 100644 doc/forum/DVD-R-based_archive_--_lack_of_backward_compatibility_seems_like_a_showstopper.mdwn diff --git a/doc/forum/DVD-R-based_archive_--_lack_of_backward_compatibility_seems_like_a_showstopper.mdwn b/doc/forum/DVD-R-based_archive_--_lack_of_backward_compatibility_seems_like_a_showstopper.mdwn new file mode 100644 index 000000000..bc89b1352 --- /dev/null +++ b/doc/forum/DVD-R-based_archive_--_lack_of_backward_compatibility_seems_like_a_showstopper.mdwn @@ -0,0 +1,15 @@ +I've been planning to use git-annex to manage a collection of DVD-Rs (of photos and the like), something along [these lines](https://git-annex.branchable.com/forum/How_do_I_backup_my_data_to_blue_ray_disks__63__/), and especially this paragraph therein: + +> If the [media is] not rewritable [which in my case it won't be; see below], I might try making the git-annex repo in a temporary directory on the hard disk, and then generating the ISO from that once I've filled it up. Should work fine, I might set "remote..annex-readonly" to true in git repos that had such a disk as a remote to let git-annex know to not try to write to it. + +But then there's this bug report: [read-only filesystem on remote prevents auto-upgrade from v3 to v5, and prevents using a remote](https://git-annex.branchable.com/bugs/annex_get_fails_from_read-only_filesystem/), and [Joey's comment]((http://git-annex.branchable.com/bugs/annex_get_fails_from_read-only_filesystem/#comment-67f204c3a4312bbda8ace305dbe0afbf): + +> From a code complication POV, it's useful for git-annex to only support one version of repository at a time. + +My concept depends on being able to restore files from my archive, N years and M git-annex versions later, using `git annex get` (after `git annex whereis` or the like to find out which volume to mount). If I can't count on the *get* to work -- and indeed, can pretty much count on it *not* to, after the next format-version bump -- this whole scheme sounds like a nonstarter. + +> As far as backwards compatablity goes, I don't anticipate ever removing the upgrade code from git-annex. + +This is an archive; therefore it will use write-once media -- if it were rewritable, it would be clobberable should something (including `git-annex upgrade`!) go wrong. + +So, is there a way around this? Or am I (and others) out of luck on using git-annex to manage long-term archival storage? -- cgit v1.2.3 From 5da9455be67393e5092af9ee964517cfac20d25e Mon Sep 17 00:00:00 2001 From: PaulK Date: Sun, 25 Sep 2016 03:08:41 +0000 Subject: Added a comment --- .../comment_7_8da1f5fc6656e92dc2e3dabd9808f2d1._comment | 13 +++++++++++++ 1 file changed, 13 insertions(+) create mode 100644 doc/bugs/git-annex_won__39__t_execute_on_WD_My_Cloud_NAS/comment_7_8da1f5fc6656e92dc2e3dabd9808f2d1._comment diff --git a/doc/bugs/git-annex_won__39__t_execute_on_WD_My_Cloud_NAS/comment_7_8da1f5fc6656e92dc2e3dabd9808f2d1._comment b/doc/bugs/git-annex_won__39__t_execute_on_WD_My_Cloud_NAS/comment_7_8da1f5fc6656e92dc2e3dabd9808f2d1._comment new file mode 100644 index 000000000..05fe1010a --- /dev/null +++ b/doc/bugs/git-annex_won__39__t_execute_on_WD_My_Cloud_NAS/comment_7_8da1f5fc6656e92dc2e3dabd9808f2d1._comment @@ -0,0 +1,13 @@ +[[!comment format=mdwn + username="PaulK" + subject="comment 7" + date="2016-09-25T03:08:40Z" + content=""" +As an aside, just tried syncthing's arm verion, and I get a \"runtime: kernel page size (32768) is larger than runtime page size (4096)\" error. While their arm64 version also won't run. + +Perhaps it's a similar issue with git-annex? Seems the page-size comes up in a number of contexts of people trying to get software running on the WD NAS. + +Is there any way to adjust this page-size in the linker? + +Thanks +"""]] -- cgit v1.2.3 From cefc9feb5b8c5521d2318f4a1c8d88947bb68606 Mon Sep 17 00:00:00 2001 From: madduck Date: Sun, 25 Sep 2016 13:25:03 +0000 Subject: --- doc/bugs/Metadata_charset_not_uniform.mdwn | 64 ++++++++++++++++++++++++++++++ 1 file changed, 64 insertions(+) create mode 100644 doc/bugs/Metadata_charset_not_uniform.mdwn diff --git a/doc/bugs/Metadata_charset_not_uniform.mdwn b/doc/bugs/Metadata_charset_not_uniform.mdwn new file mode 100644 index 000000000..19f6aa403 --- /dev/null +++ b/doc/bugs/Metadata_charset_not_uniform.mdwn @@ -0,0 +1,64 @@ +### Please describe the problem. + +Metadata are not stored in a consistent format. It seems more like git-annex chooses the "smallest" charset able to hold the data, i.e. US-ASCII, unless there are latin1 characters, and only UTF-8 if there are UTF-8 characters that are not in latin1 + +### What steps will reproduce the problem? + + % git init + Initialized empty Git repository in /home/madduck/.tmp/cdt.GlIevu/.git/ + + % git annex init + init ok + (recording state in git...) + + % date > a + + % git annex add a + add a ok + (recording state in git...) + + % git annex metadata -s one=$(echo US-ASCII | iconv -tus-ascii) a + metadata a + lastchanged=2016-09-25@13-18-57 + one=US-ASCII + one-lastchanged=2016-09-25@13-18-57 + ok + (recording state in git...) + + % git annex metadata -s two=$(echo lätin1 | iconv -tlatin1) a + metadata a + lastchanged=2016-09-25@13-19-37 + one=US-ASCII + one-lastchanged=2016-09-25@13-18-57 + two=lätin1 + two-lastchanged=2016-09-25@13-19-37 + ok + (recording state in git...) + + % git annex metadata -s three=$(echo unicode… | iconv -tutf8) a + metadata a + lastchanged=2016-09-25@13-19-41 + one=US-ASCII + one-lastchanged=2016-09-25@13-18-57 + three=unicode… + three-lastchanged=2016-09-25@13-19-41 + two=lätin1 + two-lastchanged=2016-09-25@13-19-37 + ok + (recording state in git...) + + % git annex metadata -g three a | iconv -tutf8 + unicode… + + % git annex metadata -g two a | iconv -tutf8 + liconv: illegal input sequence at position 1 + + % git annex metadata -g one a | iconv -tutf8 + US-ASCII + + % git annex metadata -g two a | iconv -flatin1 -tutf8 + lätin1 + +### What version of git-annex are you using? On what operating system? + +6.20160808-1 -- cgit v1.2.3 From d84e5ae11ac396f15f6b824e30471d74a6e2c62a Mon Sep 17 00:00:00 2001 From: "sven.rieke@2bfe1de15de1bb402f962e41f9e5bfc1be1cf8d1" Date: Sun, 25 Sep 2016 15:00:18 +0000 Subject: --- .../Assistant_does_not_update_adjusted_branch.mdwn | 89 ++++++++++++++++++++++ 1 file changed, 89 insertions(+) create mode 100644 doc/bugs/Assistant_does_not_update_adjusted_branch.mdwn diff --git a/doc/bugs/Assistant_does_not_update_adjusted_branch.mdwn b/doc/bugs/Assistant_does_not_update_adjusted_branch.mdwn new file mode 100644 index 000000000..d666401cf --- /dev/null +++ b/doc/bugs/Assistant_does_not_update_adjusted_branch.mdwn @@ -0,0 +1,89 @@ +### Please describe the problem. + +When using the assistant to synchronize several annex repositories, changes are not correctly or not at all propagated to repositories that are in the adjusted branch. + +* New files from other repositories are not created automatically in adjusted branch repos +* Commited changes in files from other repositories are not reflected in in adjusted branch repos + +The manual states: +> To propigate changes from the adjusted branch back to the original +> branch, and to other repositories, as well as to merge in changes from +> other repositories, use git annex sync. + +I would expect that the assistant is just doing this, that I don't have to trigger the sync in the adjusted branch repo by myself. + +### What steps will reproduce the problem? + +Synchronizing several git annex repositories (three) with the assistant, with the second one being in the adjusted branch: +* Create a new file in the first repository (normal v5, autocommit=true) +* The file is being commited automatically and synchronized into the 3rd repository (normal v5). +* But the file does not appear in the 2nd one, being in the adjusted branch + +Once you trigger + git annex sync +in the 2nd repository, it seems the adjusted branch synchronizes with the master and the file appears. + +The same happens with changes in files. + +### What version of git-annex are you using? On what operating system? + +* git-annex version: 6.20160511-1~ubuntu14.04.1~ppa1 +* Linux 4.4.0-24-generic #43~14.04.1-Ubuntu x86_64 +* Linux Mint 17.3 Rosa + +### Please provide any additional information below. + +Assistant log from adjust branch repo. +test7.txt is the new file created on other repo which didn't showed up immediately. + +[[!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 +(merging origin/git-annex into git-annex...) +To /home/sven/Temporary/Annex1 + + 9cc4eea...0e6c4ba git-annex -> synced/git-annex (forced update) +(started...) +(merging synced/git-annex into git-annex...) +(Merging into master...) Merge made by the 'recursive' strategy. + script.sh | 1 + + 1 file changed, 1 insertion(+) + create mode 100644 script.sh +(Merging into adjusted branch...) +Updating 449f26f..09950df +Fast-forward + script.sh | 1 + + 1 file changed, 1 insertion(+) + create mode 100644 script.sh +[2016-09-25 16:32:28.594537] Committer: Committing changes to git +(recording state in git...) +[2016-09-25 16:32:28.631525] Pusher: Syncing with origin +To /home/sven/Temporary/Annex1 + 0e6c4ba..578f070 git-annex -> synced/git-annex + 9754018..38c3683 master -> synced/master +[2016-09-25 16:32:29.632224] Committer: Committing changes to git +(recording state in git...) +[2016-09-25 16:32:30.661338] Pusher: Syncing with origin +Everything up-to-date +(merging synced/git-annex into git-annex...) +(merging synced/git-annex into git-annex...) +(recording state in git...) +git-annex: Daemon is already running. +[2016-09-25 16:36:58.360139] Committer: Adding test7.txt +add test7.txt ok +[2016-09-25 16:36:58.476985] Committer: Committing changes to git +(recording state in git...) +[2016-09-25 16:36:58.494964] Pusher: Syncing with origin +Everything up-to-date +[2016-09-25 16:36:59.575623] Committer: Adding test7.txt +add test7.txt ok +[2016-09-25 16:36:59.578454] Committer: Committing changes to git +(recording state in git...) +[2016-09-25 16:37:00.506906] Pusher: Syncing with origin +Everything up-to-date +# End of transcript or log. +"""]] + +### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders) + +I'm using git-annex a lot for synchronizing stuff between work, home, external backup discs, and now that I see the autocommit=false flag I'll surely start to use the assistant. +And the new adjust branch is perfect for one of my use cases, but not like it behaves right now. -- cgit v1.2.3 From 36793467eba52fcd4824d51fc06d6e49a8ba5103 Mon Sep 17 00:00:00 2001 From: "sven.rieke@2bfe1de15de1bb402f962e41f9e5bfc1be1cf8d1" Date: Sun, 25 Sep 2016 15:01:28 +0000 Subject: --- doc/bugs/Assistant_does_not_update_adjusted_branch.mdwn | 1 + 1 file changed, 1 insertion(+) diff --git a/doc/bugs/Assistant_does_not_update_adjusted_branch.mdwn b/doc/bugs/Assistant_does_not_update_adjusted_branch.mdwn index d666401cf..83fedbb1e 100644 --- a/doc/bugs/Assistant_does_not_update_adjusted_branch.mdwn +++ b/doc/bugs/Assistant_does_not_update_adjusted_branch.mdwn @@ -15,6 +15,7 @@ I would expect that the assistant is just doing this, that I don't have to trigg ### What steps will reproduce the problem? Synchronizing several git annex repositories (three) with the assistant, with the second one being in the adjusted branch: + * Create a new file in the first repository (normal v5, autocommit=true) * The file is being commited automatically and synchronized into the 3rd repository (normal v5). * But the file does not appear in the 2nd one, being in the adjusted branch -- cgit v1.2.3