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
34 lines
1.8 KiB
Markdown
34 lines
1.8 KiB
Markdown
A big missing peice of the assistant is doing something about the content
|
|
of old versions of files, and deleted files. In direct mode, editing or
|
|
deleting a file necessarily loses its content from the local repository,
|
|
but the content can still hang around in other repositories. So, the
|
|
assistant needs to do something about that to avoid eating up disk space
|
|
unnecessarily.
|
|
|
|
I built on recent work, that lets preferred content expressions be matched
|
|
against keys with no associated file. This means that I can run unused keys
|
|
through all the machinery in the assistant that handles file transfers, and
|
|
they'll end being moved to whatever repository wants them. To control which
|
|
repositories do want to retain unused files, and which not, I added a
|
|
`unused` keyword to preferred content expressions. Client repositories and
|
|
transfer repositories do not want to retain unused files, but backup etc
|
|
repos do.
|
|
|
|
One nice thing about this `unused` preferred content implementation is that
|
|
it doesn't slow down normal matching of preferred content expressions at
|
|
all. Can you guess why not? See [[!commit 4b55afe9e92c045d72b78747021e15e8dfc16416]]
|
|
|
|
So, the assistant will run `git annex unused` on a daily basis, and
|
|
cause unused files to flow to repositories that want them. But what if no
|
|
repositories do? To guard against filling up the local disk, there's
|
|
a `annex.expireunused` configuration setting, that can cause old unused
|
|
files to be deleted by the assistant after a number of days.
|
|
|
|
I made the assistant check if there seem to be a lot of unused files piling
|
|
up. (1000+, or 10% of disk used by them, or more space taken by unused files
|
|
than is free.) If so, it'll pop up an alert to nudge the user to configure
|
|
annex.expireunused.
|
|
|
|
Still need to build the UI to configure that, and test all of this.
|
|
|
|
Today's work was sponsored by Samuel Tardieu.
|