document the key format

This commit is contained in:
Joey Hess 2012-11-30 16:01:29 -04:00
parent 8a5c8ffa6f
commit 08eedfef5d
2 changed files with 21 additions and 1 deletions

View file

@ -11,7 +11,7 @@ to the file content.
First there are two levels of directories used for hashing, to prevent
too many things ending up in any one directory.
Each subdirectory has the name of a key in one of the
Each subdirectory has the [[name_of_a_key|key_format]] in one of the
[[key-value_backends|backends]]. The file inside also has the name of the key.
This two-level structure is used because it allows the write bit to be removed
from the subdirectories as well as from the files. That prevents accidentially

View file

@ -0,0 +1,20 @@
A git-annex key has this format:
BACKEND-sNNNN-mNNNN--NAME
For example:
SHA256E-s31390--f50d7ac4c6b9031379986bc362fcefb65f1e52621ce1708d537e740fefc59cc0.mp3
* The backend is one of the [[key-value_backends|backends]], which
are always upper-cased.
* The name field at the end has a format dependent on the backend. It is
always the last field, and is prefixed with "--". Unlike other fields,
it may contain "-" in its content. It should not contain newline characters;
otherwise nearly anything goes.
* The "-s" field is optional, and is the size of the content in bytes.
* The "-m" field is optional, and is the mtime of the file when it was
added to git-annex, expressed as seconds from the epoch.
This is currently only used by the WORM backend.
* Other fields could be added in the future, if needed.
* Fields may appear, in any order (though always before the name field).