Recent comments posted to this site:

"since most threading related bugs are timing dependant, it's doubtful that the test suite would be able to usefully test them" -- if you repeat a test enough times it'll tell you whether that test might fail under multithreading. Then git bisect can narrow down the breaking change. But it'd be reassuring to be able to run the tests with multithreading on my particular environment (the way I use git-annex) and know they pass.
Comment by Ilya_Shlyakhter Tue Sep 25 18:22:16 2018

Well, this only finds old versions of files, it does not delete them.

Even if you choose to then run git-annex-dropunused, it won't lose data unless you force it to.

Comment by joey Tue Sep 25 18:09:29 2018

Multithreaded operation is not tested, and since most threading related bugs are timing dependant, it's doubtful that the test suite would be able to usefully test them.

Comment by joey Tue Sep 25 16:57:13 2018
Do the tests test multi-threaded operations (-JN)? Is here a way to specify the number of processors to use for testing?
Comment by Ilya_Shlyakhter Tue Sep 25 16:11:40 2018

The same here on Android 8.1.0. likely because .app was build for 5, but there is nothing newer offered on Android downloads. So the Android Port is abandoned overall?

Comment by yarikoptic Tue Sep 25 00:09:52 2018
If I understand correctly, git-annex-unused will by default cause old versions of files to be lost?
Comment by Ilya_Shlyakhter Mon Sep 24 17:27:34 2018

@Ilya_Shlyakhter, it's a heuristic, what consititues a file extension is not very well defined (consider ".tar.gz" and ".not-an-extension"). The heuristic has been refined over the years, but will never be perfect. But, I don't know of any 5+ character file extensions in common use!

Comment by joey Mon Sep 24 15:42:24 2018

Indirect mode is the recommended thing to use, except for situations where it doesn't work, then direct mode is used as a fallback.

v6 is getting fairly close to working better than direct mode at this point.

Comment by joey Mon Sep 24 15:40:48 2018

@Ilya_Shlyakhter,

  1. CHECKURL is only used by git-annex add/importfeed when adding a new url. So it does not need to be consistent with CHECKPRESENT, though it would probably make sense for it to be in most cases.
  2. I guess you're asking if it should do that in its CHECKPRESENT implementation. CHECKPRESENT needs to use some method to actively verify that the remote currently contains the content of the key. It doesn't necessarily need to use a recorded url.
  3. GETURLS looks at information stored in the git-annex branch. If the url key has been added to the repository with git annex add then its url will be stored there, but if you just generated an url key, it doesn't necessarily have anything stored about it in the git-annex branch.
Comment by joey Mon Sep 24 15:35:54 2018

I've added a para above. Note that this is a wiki, and you can edit it too!

Showing the timestamp of when the file was added to the remote could be done; git-annex does not track the last time it verified content was on a remote and tracking that would bloat the git-annex branch. I don't think displaying a very old timestamp for data at rest would give the right impression though.

Comment by joey Mon Sep 24 15:33:02 2018