mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions

Added a comment

Browse source
This commit is contained in:
vrs+annex@ea5fa24dbb279be61a8e50adb638bf8366300717 2018-04-05 01:32:33 +00:00 • committed by admin
parent 9b98d3f630
commit d8af254515
1 changed files with 10 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

10
doc/bugs/annex.genmetadata_should_default_to_true/comment_2_0966f8bf944ded0a5199285ed3c12930._comment Normal file
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.
"""]]