From cefdea80735b564c77c2d2ae1e7bdc61d571c3fc Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Thu, 7 Nov 2019 13:10:39 -0400 Subject: [PATCH] results of more testing --- doc/todo/sqlite_database_improvements.mdwn | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/doc/todo/sqlite_database_improvements.mdwn b/doc/todo/sqlite_database_improvements.mdwn index 46d02aab46..b0982b95f1 100644 --- a/doc/todo/sqlite_database_improvements.mdwn +++ b/doc/todo/sqlite_database_improvements.mdwn @@ -115,6 +115,11 @@ remaining todo: > clone being used to update the export. The clone can only learn > export state from the log. It's supposed to recover from such > situations, the next time an export is run, so should be ok. +> +> An interrupted export won't resume where it left off, since the +> information about a partial export doesn't reach the git-annex branch. +> So it will re-send some files on resume. Documenting this should +> be good enough. > > Testing this an exporting to a directory with both exporttree=yes and > importtree=yes, it refused to let an interrupted export proceed after @@ -122,6 +127,15 @@ remaining todo: > problem. Guess the problem is that the content idenfifier did not > get recorded in the git-annex branch and the db value was lost on upgrade. > +> If the export is not interrupted before upgrade, later exports are able +> to overwrite the exported files as they should. +> +> Hmm, testing again, with a script, and interrupting the export, I am +> not able to reproduce the problem either. The cids of exported files +> get written to the journal, so make their way into the git-annex branch +> and so the cid db gets repopulated. Perhaps my earlier manual test +> was mistaken somehow. +> > * Keys (IKey, SFilePath, SInodeCache) > Use scanUnlockedFiles to repopulate the Associated table. >