From 8a29d197a26070bb8d6ee4813700a05fdf165c6e Mon Sep 17 00:00:00 2001 From: "https://www.google.com/accounts/o8/id?id=AItOawmBUR4O9mofxVbpb8JV9mEbVfIYv670uJo" Date: Tue, 25 Sep 2012 23:55:44 +0000 Subject: Added a comment --- .../comment_1_36ae3c75053d5ec278b5e6eb2084d57a._comment | 8 ++++++++ 1 file changed, 8 insertions(+) create mode 100644 doc/todo/wishlist:_an___34__assistant__34___for_web-browsing_--_tracking_the_sources_of_the_downloads/comment_1_36ae3c75053d5ec278b5e6eb2084d57a._comment diff --git a/doc/todo/wishlist:_an___34__assistant__34___for_web-browsing_--_tracking_the_sources_of_the_downloads/comment_1_36ae3c75053d5ec278b5e6eb2084d57a._comment b/doc/todo/wishlist:_an___34__assistant__34___for_web-browsing_--_tracking_the_sources_of_the_downloads/comment_1_36ae3c75053d5ec278b5e6eb2084d57a._comment new file mode 100644 index 000000000..4c20561c7 --- /dev/null +++ b/doc/todo/wishlist:_an___34__assistant__34___for_web-browsing_--_tracking_the_sources_of_the_downloads/comment_1_36ae3c75053d5ec278b5e6eb2084d57a._comment @@ -0,0 +1,8 @@ +[[!comment format=mdwn + username="https://www.google.com/accounts/o8/id?id=AItOawmBUR4O9mofxVbpb8JV9mEbVfIYv670uJo" + nickname="Justin" + subject="comment 1" + date="2012-09-25T23:55:44Z" + content=""" +You know about `git annex addurl` right? It doesn't help with the browser integration (though I bet there are existing download manager extensions you could re-use for this) but it takes care of the other use cases. +"""]] -- cgit v1.2.3 From cbec26163f11201d4b69e658a3a95504442a81d8 Mon Sep 17 00:00:00 2001 From: "http://lj.rossia.org/users/imz/" Date: Wed, 26 Sep 2012 00:04:03 +0000 Subject: Added a comment: the scheme to follow to use the addurl command is longer --- .../comment_2_ad3b928639ae485a43a89dab4fe9232b._comment | 8 ++++++++ 1 file changed, 8 insertions(+) create mode 100644 doc/todo/wishlist:_an___34__assistant__34___for_web-browsing_--_tracking_the_sources_of_the_downloads/comment_2_ad3b928639ae485a43a89dab4fe9232b._comment diff --git a/doc/todo/wishlist:_an___34__assistant__34___for_web-browsing_--_tracking_the_sources_of_the_downloads/comment_2_ad3b928639ae485a43a89dab4fe9232b._comment b/doc/todo/wishlist:_an___34__assistant__34___for_web-browsing_--_tracking_the_sources_of_the_downloads/comment_2_ad3b928639ae485a43a89dab4fe9232b._comment new file mode 100644 index 000000000..d124d7dd2 --- /dev/null +++ b/doc/todo/wishlist:_an___34__assistant__34___for_web-browsing_--_tracking_the_sources_of_the_downloads/comment_2_ad3b928639ae485a43a89dab4fe9232b._comment @@ -0,0 +1,8 @@ +[[!comment format=mdwn + username="http://lj.rossia.org/users/imz/" + ip="79.165.56.162" + subject="the scheme to follow to use the addurl command is longer" + date="2012-09-26T00:04:03Z" + content=""" +Justin, yes, I know. To use addurl, I should force myself not to click on a link to view it, but rather to copy it, paste into the command line with addurl (then it will be downloaded, and I can run a command to view it...). Not terrible, probably learnable. +"""]] -- cgit v1.2.3 From e31cfcc7276a6af24f97d15448bbdb5a80151741 Mon Sep 17 00:00:00 2001 From: "http://lj.rossia.org/users/imz/" Date: Wed, 26 Sep 2012 00:07:11 +0000 Subject: Added a comment: the scheme to follow to use the addurl command is longer --- .../comment_3_d9f725de41a8572c85e4c6d9b4bcc927._comment | 8 ++++++++ 1 file changed, 8 insertions(+) create mode 100644 doc/todo/wishlist:_an___34__assistant__34___for_web-browsing_--_tracking_the_sources_of_the_downloads/comment_3_d9f725de41a8572c85e4c6d9b4bcc927._comment diff --git a/doc/todo/wishlist:_an___34__assistant__34___for_web-browsing_--_tracking_the_sources_of_the_downloads/comment_3_d9f725de41a8572c85e4c6d9b4bcc927._comment b/doc/todo/wishlist:_an___34__assistant__34___for_web-browsing_--_tracking_the_sources_of_the_downloads/comment_3_d9f725de41a8572c85e4c6d9b4bcc927._comment new file mode 100644 index 000000000..30515a49b --- /dev/null +++ b/doc/todo/wishlist:_an___34__assistant__34___for_web-browsing_--_tracking_the_sources_of_the_downloads/comment_3_d9f725de41a8572c85e4c6d9b4bcc927._comment @@ -0,0 +1,8 @@ +[[!comment format=mdwn + username="http://lj.rossia.org/users/imz/" + ip="79.165.56.162" + subject="the scheme to follow to use the addurl command is longer" + date="2012-09-26T00:07:11Z" + content=""" +Justin, yes, I know. To use [[addurl|tips/using the web as a special remote]], I should force myself not to click on a link to view it, but rather to copy it, paste into the command line with addurl (then it will be downloaded, and I can run a command to view it...). Not terrible, probably learnable. +"""]] -- cgit v1.2.3 From fc14e80f8d6787a1d2bf0940b8fba5a68f709662 Mon Sep 17 00:00:00 2001 From: "http://lj.rossia.org/users/imz/" Date: Wed, 26 Sep 2012 00:07:27 +0000 Subject: removed --- .../comment_2_ad3b928639ae485a43a89dab4fe9232b._comment | 8 -------- 1 file changed, 8 deletions(-) delete mode 100644 doc/todo/wishlist:_an___34__assistant__34___for_web-browsing_--_tracking_the_sources_of_the_downloads/comment_2_ad3b928639ae485a43a89dab4fe9232b._comment diff --git a/doc/todo/wishlist:_an___34__assistant__34___for_web-browsing_--_tracking_the_sources_of_the_downloads/comment_2_ad3b928639ae485a43a89dab4fe9232b._comment b/doc/todo/wishlist:_an___34__assistant__34___for_web-browsing_--_tracking_the_sources_of_the_downloads/comment_2_ad3b928639ae485a43a89dab4fe9232b._comment deleted file mode 100644 index d124d7dd2..000000000 --- a/doc/todo/wishlist:_an___34__assistant__34___for_web-browsing_--_tracking_the_sources_of_the_downloads/comment_2_ad3b928639ae485a43a89dab4fe9232b._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="http://lj.rossia.org/users/imz/" - ip="79.165.56.162" - subject="the scheme to follow to use the addurl command is longer" - date="2012-09-26T00:04:03Z" - content=""" -Justin, yes, I know. To use addurl, I should force myself not to click on a link to view it, but rather to copy it, paste into the command line with addurl (then it will be downloaded, and I can run a command to view it...). Not terrible, probably learnable. -"""]] -- cgit v1.2.3 From 479d5f062260440d9714d9d500c0446fd3140c06 Mon Sep 17 00:00:00 2001 From: "http://lj.rossia.org/users/imz/" Date: Wed, 26 Sep 2012 00:10:33 +0000 Subject: For more clarity, link to the git-annex's cmds that the menu should be an interface for. --- ..._34___for_web-browsing_--_tracking_the_sources_of_the_downloads.mdwn | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/todo/wishlist:_an___34__assistant__34___for_web-browsing_--_tracking_the_sources_of_the_downloads.mdwn b/doc/todo/wishlist:_an___34__assistant__34___for_web-browsing_--_tracking_the_sources_of_the_downloads.mdwn index 079ad7105..c61b32b35 100644 --- a/doc/todo/wishlist:_an___34__assistant__34___for_web-browsing_--_tracking_the_sources_of_the_downloads.mdwn +++ b/doc/todo/wishlist:_an___34__assistant__34___for_web-browsing_--_tracking_the_sources_of_the_downloads.mdwn @@ -1,4 +1,4 @@ -A replacement for a web-browser's downloads menu that uses git-annex internally would be quite helpful: +A replacement for a web-browser's downloads menu that uses git-annex internally ([[`addurl`|tips/using the web as a special remote]] command for the download, and `drop` or `git rm` for the clean up) would be quite helpful: say, when working on a topic, writing a paper or similar things, I usually have a Git repo with my text, all relevant data and processing code, and possibly other backround information. It's nice to store the literature you needed at the same place where you work. (So that it is easy to catch up with what I was doing and thinking over when I left this work aside for a while, perhaps after cloning the repo from another location.) -- cgit v1.2.3 From e66798c4e4610bf89595b0d5475b7dda9fb0abd4 Mon Sep 17 00:00:00 2001 From: "https://www.google.com/accounts/o8/id?id=AItOawlatTbI0K-qydpeYHl37iseqPNvERcdIMk" Date: Wed, 26 Sep 2012 00:16:36 +0000 Subject: --- ...OSX_alias_permissions_and_versions_problem.mdwn | 31 ++++++++++++++++++++++ 1 file changed, 31 insertions(+) create mode 100644 doc/bugs/OSX_alias_permissions_and_versions_problem.mdwn diff --git a/doc/bugs/OSX_alias_permissions_and_versions_problem.mdwn b/doc/bugs/OSX_alias_permissions_and_versions_problem.mdwn new file mode 100644 index 000000000..9bdde0e1f --- /dev/null +++ b/doc/bugs/OSX_alias_permissions_and_versions_problem.mdwn @@ -0,0 +1,31 @@ +What steps will reproduce the problem? + +Use assistant and create repository the a folder in home dir. +Use textedit and save a new txt to the repository folder. + +What is the expected output? What do you see instead? + +The alias solution is broken. It should work more like Dropbox. +Textedit saves the file initially, but it is immediately locked. +Since it autosaves, it asks to unlock or duplicate. +Then gives the error: +"The file “Untitled 16.txt” cannot be unlocked." + +If the file exists: +The document “Untitled 14” could not be saved as “Untitled 14.txt”. You don’t have permission. + +If you open a file from the repository (now replaced by a symlink) with textedit, there are other problems: +- The filename will not be correct (will show the sha hash). +- It will ask to unlock, then give the error "You don’t have permission to write to the folder that the file “SHA256E-s8--8985d9832de2e28b5e1af64258c391a34d7528709ef916bac496e698c139020c.txt” is in." + +What version of git-annex are you using? On what operating system? + +OSX Lion +git-annex version: 3.20120924 + +Please provide any additional information below. + +Even if you fix these problems, automatic versioning in lion will probably don't work, and the symlinks seem a hackish solution and don't seem intuitive or easy to the end user. +The sync should be transparent but it's not, and it's error prone. It would even be best to keep file copies in the git repo and sync them with the original folder than make symlinks. + +Dropbox even allows to put a symlink in the dropbox directory, and it will sync the file. -- cgit v1.2.3 From 7de4ce4a86776a0a41e4a0e2d9917795da106c28 Mon Sep 17 00:00:00 2001 From: "http://lj.rossia.org/users/imz/" Date: Wed, 26 Sep 2012 17:37:53 +0000 Subject: A different view: extend the key-value backends with ways to look for the content in other content-addressable storage systems --- ...network_data_stores___40__gnunet__44___freenet__41__.mdwn | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/doc/todo/wishlist:_spec.remotes_for_other_peer_network_data_stores___40__gnunet__44___freenet__41__.mdwn b/doc/todo/wishlist:_spec.remotes_for_other_peer_network_data_stores___40__gnunet__44___freenet__41__.mdwn index 75d446d4b..33928b6bd 100644 --- a/doc/todo/wishlist:_spec.remotes_for_other_peer_network_data_stores___40__gnunet__44___freenet__41__.mdwn +++ b/doc/todo/wishlist:_spec.remotes_for_other_peer_network_data_stores___40__gnunet__44___freenet__41__.mdwn @@ -11,3 +11,15 @@ So, a copy in peer networks shouldn't be counted on by git-annex as much as a co (Think of such a scenario: I could save some of my public large data on external disks/DVDs and keep them at home, and also put them onto peer networks with the same nterface of git-annex which I would be used to; I would also use the git-annex interface to check from time to time that the content is still present, i.e. "cached", on the peer networks. Whenever I'm away from home, and unexpectedly need to show this content to someone, or have a look at it for some reason, I could get it from the peer network "cache".) Also networks like namecoin (derived from bitcoin) can be used as a key-value store. Despite being a peer network, a system like namecoin actually could offer the publisher more control over the lifespan of the content: he should be able to offer "financial" reward for others processing his key-value data. (But I'm not sure namecoin is designed reasonably for this reward system to work actually; but there might be appearing other similar systems.) + +## A different view: extend the key-value backends with ways to look for the content in other content-addressable storage systems +We might want to look for the registered files in other [content-addressable storage systems](http://en.wikipedia.org/wiki/Content-addressable_storage#Open-source_implementations) (and also to be able to put the files there for storage). + +For example: + +* [**GNUnet**](http://en.wikipedia.org/wiki/Gnunet) uses its own hash format to address the content. git-annex could extend its own [[backends]] with a one to work with GNUnet, and by default have a built-in [[special remote|special remotes]] that would interact with GNUnet when looking for a content or storing some content. No special setup of the special remote in each repo should be necessary, because GNUnet is "global", so we'd just use the user's already configured GNUnet client. Just turning the builtin GNUnet special remote on or off should be an option (in the repo configuration, and when calling the commands that would query it, like `whereis`). +* **freenet** is similar. +* Similarly, a backend for the hashes used in **BitTorrent** and **magnet links** could be used. If we want a trackerless mode, then probably it's a similar case for a "global"/built-in special remote that needs no local setup in each repo. Using a selected tracker would mean setting up a special remote in our repo. +* **Git** itself can be viwed as place to look for the content. There could be a corresponding backend and a builtin special remote (needing no extra setup) to look for the content among the objects stored in the local Git repo. (What if we have a copy of a file that we've put under the control of git-annex in a previous Git commit? We could get it from the object store of Git.) +* **Venti**, [[**Tahoe-LAFS**|todo/tahoe lfs for reals]] would need a backend for their hashes, and a specially setup special remote in each repo where we'd like to use them--because these are not "global" system, we must setup the path to the instance of the filesystem we'd like to use. +* probably, there must be other interesting cases of this kind.... (I'm also thinking about using somethng like a bibliogrphic information as a key, but then it wouldn't guarantee identical files: the same paper can be stored in diffrent formats, etc.) -- cgit v1.2.3 From cfb060e93b0eb5eef7a9073d6184301fae773472 Mon Sep 17 00:00:00 2001 From: "http://lj.rossia.org/users/imz/" Date: Wed, 26 Sep 2012 18:20:07 +0000 Subject: Cf. URNs -- what about extendings keys to URNs? The there's no guarantee that will get the identified content in always the same format. --- ...other_peer_network_data_stores___40__gnunet__44___freenet__41__.mdwn | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/todo/wishlist:_spec.remotes_for_other_peer_network_data_stores___40__gnunet__44___freenet__41__.mdwn b/doc/todo/wishlist:_spec.remotes_for_other_peer_network_data_stores___40__gnunet__44___freenet__41__.mdwn index 33928b6bd..0e3d8ac0a 100644 --- a/doc/todo/wishlist:_spec.remotes_for_other_peer_network_data_stores___40__gnunet__44___freenet__41__.mdwn +++ b/doc/todo/wishlist:_spec.remotes_for_other_peer_network_data_stores___40__gnunet__44___freenet__41__.mdwn @@ -22,4 +22,4 @@ For example: * Similarly, a backend for the hashes used in **BitTorrent** and **magnet links** could be used. If we want a trackerless mode, then probably it's a similar case for a "global"/built-in special remote that needs no local setup in each repo. Using a selected tracker would mean setting up a special remote in our repo. * **Git** itself can be viwed as place to look for the content. There could be a corresponding backend and a builtin special remote (needing no extra setup) to look for the content among the objects stored in the local Git repo. (What if we have a copy of a file that we've put under the control of git-annex in a previous Git commit? We could get it from the object store of Git.) * **Venti**, [[**Tahoe-LAFS**|todo/tahoe lfs for reals]] would need a backend for their hashes, and a specially setup special remote in each repo where we'd like to use them--because these are not "global" system, we must setup the path to the instance of the filesystem we'd like to use. -* probably, there must be other interesting cases of this kind.... (I'm also thinking about using somethng like a bibliogrphic information as a key, but then it wouldn't guarantee identical files: the same paper can be stored in diffrent formats, etc.) +* probably, there must be other interesting cases of this kind.... (I'm also thinking about using somethng like a bibliogrphic information as a key, but then it wouldn't guarantee identical files: the same paper can be stored in different formats, etc. Cf. , via .) -- cgit v1.2.3 From 3f71708083a5eec5b32306a7c2b6c7cc1e92f041 Mon Sep 17 00:00:00 2001 From: "http://lj.rossia.org/users/imz/" Date: Wed, 26 Sep 2012 18:28:31 +0000 Subject: Any URN is different from a hash in that it isn't computable. It must be known. --- ...ther_peer_network_data_stores___40__gnunet__44___freenet__41__.mdwn | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/doc/todo/wishlist:_spec.remotes_for_other_peer_network_data_stores___40__gnunet__44___freenet__41__.mdwn b/doc/todo/wishlist:_spec.remotes_for_other_peer_network_data_stores___40__gnunet__44___freenet__41__.mdwn index 0e3d8ac0a..545bd861d 100644 --- a/doc/todo/wishlist:_spec.remotes_for_other_peer_network_data_stores___40__gnunet__44___freenet__41__.mdwn +++ b/doc/todo/wishlist:_spec.remotes_for_other_peer_network_data_stores___40__gnunet__44___freenet__41__.mdwn @@ -22,4 +22,5 @@ For example: * Similarly, a backend for the hashes used in **BitTorrent** and **magnet links** could be used. If we want a trackerless mode, then probably it's a similar case for a "global"/built-in special remote that needs no local setup in each repo. Using a selected tracker would mean setting up a special remote in our repo. * **Git** itself can be viwed as place to look for the content. There could be a corresponding backend and a builtin special remote (needing no extra setup) to look for the content among the objects stored in the local Git repo. (What if we have a copy of a file that we've put under the control of git-annex in a previous Git commit? We could get it from the object store of Git.) * **Venti**, [[**Tahoe-LAFS**|todo/tahoe lfs for reals]] would need a backend for their hashes, and a specially setup special remote in each repo where we'd like to use them--because these are not "global" system, we must setup the path to the instance of the filesystem we'd like to use. -* probably, there must be other interesting cases of this kind.... (I'm also thinking about using somethng like a bibliogrphic information as a key, but then it wouldn't guarantee identical files: the same paper can be stored in different formats, etc. Cf. , via .) +* probably, there must be other interesting cases of this kind... +* (I'm also thinking about using somethng like a **bibliographic information** as a key, but then it wouldn't guarantee identical files: the same paper can be stored in different formats, etc. Cf. [**URNs**](http://en.wikipedia.org/wiki/Uniform_resource_name#Examples), via . Also, an URN like bibliographic information can't be computed from the file, it will have to be entered manually or obtained from another directory of URNs.) -- cgit v1.2.3