2011-03-04 16:31:01 +00:00
|
|
|
Imagine putting a git-annex drive in a time capsule. In 20, or 50, or 100
|
|
|
|
|
years, you'd like its contents to be as accessible as possible to whoever
|
|
|
|
|
digs it up.
|
|
|
|
|
|
2013-05-22 19:42:25 +00:00
|
|
|
This is a hard problem. git-annex cannot completely solve it, but it does
|
2011-03-04 16:31:01 +00:00
|
|
|
its best to not contribute to the problem. Here are some aspects of the
|
|
|
|
|
problem:
|
|
|
|
|
|
|
|
|
|
* How are files accessed? Git-annex carefully adds minimal complexity
|
|
|
|
|
to access files in a repository. Nothing needs to be done to extract
|
|
|
|
|
files from the repository; they are there on disk in the usual way,
|
|
|
|
|
with just some symlinks pointing at the annexed file contents.
|
|
|
|
|
Neither git-annex nor git is needed to get at the file contents.
|
2011-03-05 19:58:57 +00:00
|
|
|
|
|
|
|
|
(Also, git-annex provides an "uninit" command that moves everything out
|
|
|
|
|
of the annex, if you should ever want to stop using it.)
|
2011-03-04 16:31:01 +00:00
|
|
|
|
|
|
|
|
* What file formats are used? Will they still be readable? To deal with
|
|
|
|
|
this, it's best to stick to plain text files, and the most common
|
|
|
|
|
image, sound, etc formats. Consider storing the same content in multiple
|
|
|
|
|
formats.
|
|
|
|
|
|
|
|
|
|
* What filesystem is used on the drive? Will that filesystem still be
|
2012-02-15 23:46:29 +00:00
|
|
|
available? Whatever you choose to use, git-annex can put files on it.
|
|
|
|
|
Even if you choose (ugh) FAT.
|
2011-03-04 16:31:01 +00:00
|
|
|
|
|
|
|
|
* What is the hardware interface of the drive? Will hardware still exist
|
|
|
|
|
to talk to it?
|
2011-03-09 05:56:24 +00:00
|
|
|
|
|
|
|
|
* What if some of the data is damaged? git-annex facilitates storing a
|
|
|
|
|
configurable number of [[copies]] of the file contents. The metadata
|
|
|
|
|
about your files is stored in git, and so every clone of the repository
|
|
|
|
|
means another copy of that is stored. Also, git-annex uses filenames
|
|
|
|
|
for the data that encode everything needed to match it back to the
|
|
|
|
|
metadata. So if a filesystem is badly corrupted and all your annexed
|
|
|
|
|
files end up in `lost+found`, they can easily be lifted back out into
|
2011-03-09 19:59:44 +00:00
|
|
|
another clone of the repository. Even if the filenames are lost,
|
2011-11-08 16:23:03 +00:00
|
|
|
it's possible to [[tips/recover_data_from_lost+found]].
|
2016-01-08 15:48:53 +00:00
|
|
|
|
2016-10-05 20:29:32 +00:00
|
|
|
* What about upgrades to the git-annex repisitory format?
|
|
|
|
|
git-annex supports [[upgrades]] from all previous repository versions,
|
|
|
|
|
and will always support upgrading from all of them to any new versions.
|
|
|
|
|
Note that the upgrade process needs to modify the content of the
|
|
|
|
|
repository -- if modifying the original archived repository is not
|
|
|
|
|
desirable you can always make a copy of the repository and upgrade the
|
|
|
|
|
copy.
|
|
|
|
|
|
2016-01-08 15:48:53 +00:00
|
|
|
* What about encrypted special remotes? A
|
|
|
|
|
[[fairly simple shell script using standard tools|Decrypting_files_in_special_remotes_without_git-annex]]
|
|
|
|
|
(gpg and openssl) can decrypt files stored on such
|
|
|
|
|
a remote, as long as you have access to the encryption keys (which
|
|
|
|
|
are stored in the git-annex branch of the repository, sometimes
|
|
|
|
|
encrypted with your gpg key).
|
