blob: d6db3556836e20493c4363e16744c6ae09fda20b (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
|
[[!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.
"""]]
|
