32 lines
1.7 KiB
Text
32 lines
1.7 KiB
Text
[[!comment format=mdwn
|
|
username="https://launchpad.net/~stephane-gourichon-lpad"
|
|
nickname="stephane-gourichon-lpad"
|
|
avatar="http://cdn.libravatar.org/avatar/02d4a0af59175f9123720b4481d55a769ba954e20f6dd9b2792217d9fa0c6089"
|
|
subject="Bitten again by "E" backend, wish "e" backend."
|
|
date="2016-10-30T19:19:21Z"
|
|
content="""
|
|
Changing file extension is arguably not a very common use case. But changing extension case is more common, especially when copying files from FAT filesystems through different ways (Card reader, plugging device directly), and causes troubles.
|
|
|
|
# Concrete case
|
|
|
|
A set of files were imported with extension NEF and JPG, by mistake (forgot to rename them first), using default (or is it?) backend SHA256E.
|
|
|
|
When using `git annex reinject --known` to cleanup another copy, files were not detected as known.
|
|
|
|
This will happen again and feels not very good.
|
|
|
|
# Workaround
|
|
|
|
Thanks to CandyAngel I know I can rename then use `git annex migrate --force` and `reinject` again.
|
|
|
|
# Better solution
|
|
|
|
A SHA256e backend (that squashes extensions to lowercase) would not have this problem.
|
|
|
|
# Additional information
|
|
|
|
Why not switch to plain SHA256 backend? I'm a little paranoid (which makes me a good fit for using git-annex overall).
|
|
|
|
One of the reason I use git-annex is that its storage format is actually simple, and files can be accessed even on a computer that can read the plain filesystem, without git or git-annex required. But in the lifetime of a filesystem, many bad things can happen and details of storage format may make a difference in case of major recovery (or even sanity check) scenario. Hashes without extension feel somehow uncomfortable. Lowercase extension backends feel much better.
|
|
|
|
"""]]
|