e213ef310f
* Fix minor FD leak in journal code. Closes: #754608 * direct: Fix handling of case where a work tree subdirectory cannot be written to due to permissions. * migrate: Avoid re-checksumming when migrating from hashE to hash backend. * uninit: Avoid failing final removal in some direct mode repositories due to file modes. * S3: Deal with AWS ACL configurations that do not allow creating or checking the location of a bucket, but only reading and writing content to it. * resolvemerge: New plumbing command that runs the automatic merge conflict resolver. * Deal with change in git 2.0 that made indirect mode merge conflict resolution leave behind old files. * sync: Fix git sync with local git remotes even when they don't have an annex.uuid set. (The assistant already did so.) * Set gcrypt-publish-participants when setting up a gcrypt repository, to avoid unncessary passphrase prompts. This is a security/usability tradeoff. To avoid exposing the gpg key ids who can decrypt the repository, users can unset gcrypt-publish-participants. * Install nautilus hooks even when ~/.local/share/nautilus/ does not yet exist, since it is not automatically created for Gnome 3 users. * Windows: Move .vbs files out of git\bin, to avoid that being in the PATH, which caused some weird breakage. (Thanks, divB) * Windows: Fix locking issue that prevented the webapp starting (since 5.20140707). # imported from the archive
55 lines
1.8 KiB
Markdown
55 lines
1.8 KiB
Markdown
### Please describe the problem.
|
|
|
|
`git annex status` inconsistently uses mebi (SI) and giga (informal) prefixes.
|
|
|
|
### What steps will reproduce the problem?
|
|
|
|
Example:
|
|
|
|
[[!format txt """
|
|
anarcat@marcos:mp3$ git annex status
|
|
supported backends: SHA256E SHA1E SHA512E SHA224E SHA384E SHA256 SHA1 SHA512 SHA224 SHA384 WORM URL
|
|
supported remote types: git S3 bup directory rsync web glacier hook
|
|
repository mode: direct
|
|
trusted repositories: 0
|
|
semitrusted repositories: 2
|
|
00000000-0000-0000-0000-000000000001 -- web
|
|
b7802161-c984-4c9f-8d05-787a29c41cfe -- here (anarcat@marcos:/srv/mp3)
|
|
untrusted repositories: 0
|
|
transfers in progress: none
|
|
available local disk space: 31.93 gigabytes (+1 megabyte reserved)
|
|
local annex keys: 19913
|
|
local annex size: 111.08 gigabytes
|
|
known annex keys: 20085
|
|
known annex size: 111.38 gigabytes
|
|
bloom filter size: 16 mebibytes (3.1% full)
|
|
backend usage:
|
|
SHA256E: 39998
|
|
"""]]
|
|
|
|
Notice `mebibytes` and `gigabytes`. It is unclear whether those are gigabytes (1000^3) or gibibytes (1024^3).
|
|
|
|
### What version of git-annex are you using? On what operating system?
|
|
|
|
4.20130802~bpo70+2, Debian wheezy.
|
|
|
|
### Please provide any additional information below.
|
|
|
|
nil. --[[anarcat]]
|
|
|
|
> git-annex consistently uses the powers of ten units
|
|
> for disk storage sizes. Its "gigabyte" is the SI gigabyte.
|
|
>
|
|
> It uses the absurdly named units for powers of 2 for memory sizes,
|
|
> in the few places it deals with memory (probably only the above bloom
|
|
> filter size number).
|
|
>
|
|
> AFAIK I am complying with all relevant standards and best practices.
|
|
> Even though I consider them rather dumb, as is clear if you
|
|
> [read the opionated source code I wrote to handle this]().
|
|
>
|
|
> If git-annex used "gibibyte", the numbers it reports for disk size
|
|
> would not match the numbers disk vendors and most tools use.
|
|
>
|
|
> [[bug_is_in_world_not_in_git-annex|done]] --[[Joey]]
|
|
|