Added a comment
This commit is contained in:
parent
9b98d3f630
commit
d8af254515
1 changed files with 10 additions and 0 deletions
|
@ -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.
|
||||
"""]]
|
Loading…
Add table
Add a link
Reference in a new issue