comment
This commit is contained in:
parent
f7fc60ed8d
commit
0f9eafc157
1 changed files with 20 additions and 0 deletions
|
@ -0,0 +1,20 @@
|
||||||
|
[[!comment format=mdwn
|
||||||
|
username="joey"
|
||||||
|
subject="""comment 1"""
|
||||||
|
date="2018-09-24T15:45:07Z"
|
||||||
|
content="""
|
||||||
|
What you're suggesting with the full filenames is basically on the same
|
||||||
|
level of complexity as direct mode or v6's unlocked files, which both avoid
|
||||||
|
symlinks and so avoid problems with the rare program that looks at the
|
||||||
|
extension of a symlink target, instead of the extension of the symlink.
|
||||||
|
|
||||||
|
Doing something to allow longer extensions is maybe worth talking more
|
||||||
|
about though. I am not very keen on adding a parameter to the backend name.
|
||||||
|
|
||||||
|
The way git-annex picks extensions doesn't need to be stable across all
|
||||||
|
versions of git-annex, because it's only done when initially adding a file,
|
||||||
|
and then the key, with whatever extension, is added as-is and git-annex
|
||||||
|
does not care about the extension thereafter. So, a
|
||||||
|
configuration setting to pick the extension length, or something like that,
|
||||||
|
would be possible to add.
|
||||||
|
"""]]
|
Loading…
Reference in a new issue