From 4ffd99c02c4e8fea50e2d2e4868098cb352d5f07 Mon Sep 17 00:00:00 2001 From: "vrs+annex@ea5fa24dbb279be61a8e50adb638bf8366300717" Date: Sat, 17 Mar 2018 19:05:38 +0000 Subject: [PATCH] --- doc/bugs/proposal_for_timestamp_semantics.mdwn | 11 +++++++++++ 1 file changed, 11 insertions(+) create mode 100644 doc/bugs/proposal_for_timestamp_semantics.mdwn diff --git a/doc/bugs/proposal_for_timestamp_semantics.mdwn b/doc/bugs/proposal_for_timestamp_semantics.mdwn new file mode 100644 index 0000000000..51121719c2 --- /dev/null +++ b/doc/bugs/proposal_for_timestamp_semantics.mdwn @@ -0,0 +1,11 @@ +# High level overview: +* This only concerns mtime (and its equivalents on other systems, if applicable). atime, ctime and permissions are out of scope. +* An object added to an annex and later retrieved from it via `mv`, `cp -L`, `git annex unannex` and such should always keep its mtime, even if retrieved on an entirely different machine and/or from a backend that doesn't support timestamps natively. +* If an added/reinjected object is already known to the annex, use the older mtime by default, since that's probably the version that's had its metadata preserved better. + * If that's too much of an assumption, provide a switch to use the older/newer/known/unknown mtime, or add a git-annex-touch command. +* symlink and object file mtimes should reflect the mtime tracked by the annex. +* ideally, directory mtimes would also be preserved, or failing that, `git-annex-fix`, `git-annex-add` and `git-checkout` should leave them untouched. + +# open questions/ideas: +* What if the user `touch`es a file/symlink, bypassing git-annex? Should the data be reconciled or ignored? +* preserving directory mtimes looks tricky, but could it maybe be done from a hook or two?