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 First there are two levels of directories used for hashing, to prevent
too many things ending up in any one directory. 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. [[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 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 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).