From 9df9a3f82bddbd41fc7fd74847d5d7e9bbcd4f32 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Tue, 5 Mar 2019 14:55:22 -0400 Subject: [PATCH] more todo --- doc/todo/import_tree.mdwn | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) diff --git a/doc/todo/import_tree.mdwn b/doc/todo/import_tree.mdwn index 7eee2722b8..c40cc5a89e 100644 --- a/doc/todo/import_tree.mdwn +++ b/doc/todo/import_tree.mdwn @@ -10,6 +10,26 @@ this. ## implementation notes +* startExport uses checkPresentExport, but when there's a modified file, + it's not unexported, so it present, so checkPresentExport succeeds, + and so startExport does the wrong thing. Seems to indicate checkPresentExport + needs to be replaced too. + +* Is renameExport safe to use with an import? + + When a rename() is done, it could result in a modified file being + renamed. But this would not result in data loss; the next import would + see the modification and import it from the new name. The only + potentially confusing thing is that there was essentially a conflict, and + it got resolved in a way the user may not expect. + + But.. S3 implements rename as a copy followed by a + delete. But if there's a race, that means that the modified content does + get deleted. + + So, it seems it's not safe. + Probably simplest to just make it not be provided for import remotes. + * Should the ContentIdentifier db be multiwriter? It would simplify the situation with the long-lived lock of it in adjustExportImport