Added a comment

This commit is contained in:
vrs+annex@ea5fa24dbb279be61a8e50adb638bf8366300717 2018-04-05 01:32:33 +00:00 committed by admin
parent 9b98d3f630
commit d8af254515

View file

@ -0,0 +1,10 @@
[[!comment format=mdwn
username="vrs+annex@ea5fa24dbb279be61a8e50adb638bf8366300717"
nickname="vrs+annex"
avatar="http://cdn.libravatar.org/avatar/74219abcec6eece8e2c9d4351c2c912c"
subject="comment 2"
date="2018-04-05T01:32:32Z"
content="""
1. Not losing data (or alternatively having a great big warning in the manual, or requiring it as a configuration step) should be the default in software that manages files, especially software that advertises a backup usecase on its front page. I do think the current implementation could be improved, which is what I opened <https://git-annex.branchable.com/bugs/file_modification_time_should_be_stored_in_exactly_one_metadata_field/> for. If that's not enough, a simple binary format should do the trick at about the same overhead as regular filesystems while staying future-proof.
2. Implementing timestamps with a field name that doesn't clash with existing fields should avoid this issue.
"""]]