Currently views mangle filenames to be unique by converting a file named "foo/bar.ext" to "bar_%foo.ext". That is kind of ugly and weird.
But also in views, metadata like author="fred/barney" is made into a directory that looks like "fred/barney" but the / is a different unicode character that looks like a regular /.
So, why not also use that in the filename mangling? Then a view could have a "fred/barney" subdirectory containing a "foo/bar.ext" file!
The unicode might pose challenages for users typing the filename, but probably users will tab complete or use a gui anyway. If that did cause a problem for some users, there could be a config added to disable the unicode.
How to handle upgrading git-annex when a view branch is checked out, if this change is made? It seems it would need to handle both the new and the old names when unmangeling (in dirFromViewedFile). Perhaps something additional could be recorded when entering a view branch that indicates what kind of name mangling was used, so it doesn't have to try both. --Joey
When several files are in a deep directory tree like
foo/bar/baz
, that would be an annoying common prefix to deal with, which the current mangling avoids. So perhaps keeping it postfix is still a good idea, but it could still use the psdudoslash. Eg,somefile@foo/bar/baz.ext
? --Joey
Related: Configuring metadata view filenames
Hardly the only place ecryptfs's filename length limits have caused problems to git-annex users. SHA256, for example is generally too long for it.
It seems to me that the only other thing git-annex could do re mangling filenames in views is to append a SHA1 of the path to the filename. Or perhaps when there is a "foo", use the name "foo.2" for the second foo. That would also guarantee it's unique, but it seems strictly worse than the current behavior of using the path for that. It prevents the user from telling which of two "foo" files is which. (Also it would need a lookup table to be maintained.)
I think it's ok if a feature can't be used on a filesystem that is too limited to support it.