If git-annex-testremote fails midway for some reason, it leaves many files on the remote that were used for the test. Maybe, add a command to clean up / drop these files? Or can an existing command do that?
If git-annex-testremote fails midway for some reason, it leaves many files on the remote that were used for the test. Maybe, add a command to clean up / drop these files? Or can an existing command do that?
Like the man page for this command says, it's best to make a new remote for testing purposes, not use a production one.
I think that a simple improvement to it would be for it to generate the same test keys every time. Then if it failed once or was interrupted or the remote was buggy, once that got fixed the same command could be run again, and would clean up the test keys that were earlier stored on the remote.
It's generating random data and a key from that, but a predictable random data would not impair the test really. Although testExportTree currently starts with a test that might fail if the key is already present in the remote.
Problem with that idea: testremote makes variants of the remote with shared encryption enabled. So the content being stored on the remote is not only random, but is encrypted with a random key. It would have to initialize the encrypted remote with a fixed encryption key. This would need some significant changes to accomplish.
My fault for not re-reading the webpage.
There's some value, I think, in being able to test production remotes. There's always a chance that a test remote got configured differently than a production one, so there's more confidence from having tested the production remote.
If find/prefer keys by file extension in key could be implemented, one could delete keys matching
*.this-is-a-test-key.The keys used by testremote never reach the git-annex branch, so there is not a way to list them.
What would work is to make testremote record the keys it stores to a log file, and then it could clean up ones from previous runs.
Yes -- I thought to suggest that but was thinking of a file the user has to deal with, which is clumsy. But I think you're suggesting a file somewhere under
.git/annex, which would be a clean solution.