Recent comments posted to this site:

It's actually a nice and helpful piece of info. I'm glad that you shared this useful information with us. Please keep us up to data like this. Thanks for sharing, for more info like this you can also try the https://printertechsupportnumbers.com/blog/how-to-fix-canon-printer-offline-error/ that even gives the perfect solution for any tech problem
Comment by RannyJohns Wed Nov 21 15:10:45 2018

The scenario that isStableKey is being used to guard against is two repos downloading the content of an url and each getting different content, followed by one repo uploading some chunks of its content and then the other repo "finishing" the upload with chunks of its different content. That would result in a mismash of chunks being stored in the remote.

It's true that it could also happen using WORM with an url attached to it. (Not with other types of keys that verify a checksum.) Though it seems much less likely, since the file size is at least checked for WORM, while with URL keys there's often no recorded file size. And, WORMs don't typically have urls attached (I can't think of a single time I've ever done that, it just feels like asking for trouble), while URL keys always do.

If this is a serious concern, I'd suggest you open a todo or bug report about it, there are far too many comments to wade through here already. We could think about, perhaps not allowing download of WORM keys from urls or something like that..

Comment by joey Tue Nov 13 04:11:47 2018

As usually, create a directory on the server, git init, then git-annex init there.

Add that locally: git remote add my-server-name my-server:~/my-repo

git-annex sync locally seems to work fine and pushes data to the server.

I needed to have this workaround before, because I could not get data from my laptop while on the server (I wasn't sure I had an open IP address for my laptop). This is mostly a basic thing in git, but I had errors with git-annex earlier and I try to be cautious now.

Comment by metst13 Tue Nov 6 20:00:13 2018

I must add that after the previous commands finished, content of the repository was not shown on the server (it was all in .git). I made

git checkout synced/master

and files appeared. Unfortunately it seems all timestamps were new, which I didn't like, and it was already asked here (http://git-annex.branchable.com/todo/does_not_preserve_timestamps/).

Comment by metst13 Tue Nov 6 20:00:13 2018

This would be super useful for my sorting annex! Being able to just drop the symlinks into other git-annex repositories and fetch the file from any of the "storage" ones (acting as caches) resolves transfer between git-annexes in a very neat and safe way!

I see that git-annex won't merge the cache's git-annex branch with this setup (which is great, because some of them are huge) but when a repo fetches a file from the cache, it will note that the cache repo had the file in the location log, right? Can this be avoided so the cache is entirely transient (once you remove the remote, there is no trace of it at all)?

Comment by CandyAngel Fri Nov 2 15:36:32 2018
I just tried this and git-annex doesn't add the cache in the location tracking for the files. Perfect! Yay! :D
Comment by CandyAngel Fri Nov 2 15:36:32 2018
Backend.hs classifies keys as "stable" or not, with URL keys being unstable. How is this distinction used? I found only one place where it's used, but couldn't quite understand it. If "stable" means "containing a hash of the content", then wouldn't WORM keys be unstable too?
Comment by Ilya_Shlyakhter Fri Nov 2 15:36:32 2018

It's only used to avoid uploading one chunk from one object that the key points to, and then later upload a chunk from a different object.

While WORM keys could in theory "collide" and the same key point to different content, that's no different than MD5 or SHA1 keys colliding; it's a smallish risk, easily quantified, and you take that risk by choosing to use those keys.

The risk that the content at an url might change varies over time or something like that, so I think it makes sense to treat URL keys as specially unstable.

Comment by joey Fri Nov 2 15:36:32 2018

"The risk that the content at an url might change varies over time or something like that, so I think it makes sense to treat URL keys as specially unstable." -- but, if I understand correctly, a URL key does not actually represent a URL? Rather, a URL can be attached to any key, and if the contents of some URLs claimed by a remote is unstable, such remotes should be marked as untrusted; while if the contents of a URL key is stored in a trusted remote, that contents is not unstable. But URL and WORM keys are both "unstable" in that their contents can't be verified.
[[todo/alternate_keys_for_same_content] could mitigate that.

Comment by Ilya_Shlyakhter Fri Nov 2 15:36:32 2018

@Ilya, the uses for CHECKURL-MULTI are open-ended, bittorrent files that can list several files is one example of a way it's used.

Comment by joey Fri Nov 2 15:36:32 2018