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
23 lines
862 B
Markdown
23 lines
862 B
Markdown
Currently, `git annex status` only shows the size of 1 copy of each file.
|
|
If numcopies is being used for redundancy, much more disk can actually be
|
|
in use than status shows.
|
|
|
|
One idea:
|
|
|
|
known annex size: 2 terabytes (plus 4 terabytes of redundant copies)
|
|
|
|
But, to get that number, it would have to walk every location log,
|
|
counting how many copies currently exist of each file. That would make
|
|
status a lot slower than it is.
|
|
|
|
One option is to just put it at the end of the status:
|
|
|
|
redundancy: 300% (4 terabytes of copies)
|
|
|
|
And ctrl-c if it's taking too long.
|
|
|
|
Hmm, fsck looks at that same info. Maybe it could cache the redundancy
|
|
level it discovers? Since fsck can be run incrementally, it would be tricky
|
|
to get an overall number. And the number would tend to be stale, but
|
|
then again it might also be nice if status shows how long ago the last fsck
|
|
was.
|