followup

Assistant, repair: Improved filtering out of git fsck lines about duplicate file entries in tree objects.

Added a comment: fsck filename

Added a comment: why option vs manual chmod

hmm

devblog

response

Merge branch 'master' of ssh://git-annex.branchable.com

close

comment

importfeed: Drop URL parameters from file extension.

Thanks, James MacMahon.

Improve style of offline html build of website.

Added a comment: re: comment 1

followup

response

response

close

response

upgrade: Handle upgrade to v6 when the repository already contains v6 unlocked files whose content is already present.

Closes https://github.com/datalad/datalad/issues/1020

The use of runWriter in scanUnlockedFiles broke due to this change;
it failed with blocked indefinitely in mvar, because the database write
handle was taken while linkFromAnnex needed to also write to it (to update
the inode cache). So, switched to using a separate runWriter for each call
to addAssociatedFileFast. A little less efficient, but not greatly; the
writes should all still be cached.

refactor

note

comment

Merge branch 'master' of ssh://git-annex.branchable.com

lock: Fix edge cases where data loss could occur in v6 mode.

In the case where the pointer file is in place, and not the content
of the object, lock's  performNew was called with filemodified=True,
which caused it to try to repopulate the object from an unmodified
associated file, of which there were none. So, the content of the object
got thrown away incorrectly. This was the cause (although not the root
cause) of data loss in https://github.com/datalad/datalad/issues/1020

The same problem could also occur when the work tree file is modified,
but the object is not, and lock is called with --force. Added a test case
for this, since it's excercising the same code path and is easier to set up
than the problem above.

Note that this only occurred when the keys database did not have an inode
cache recorded for the annex object. Normally, the annex object would be in
there, but there are of course circumstances where the inode cache is out
of sync with reality, since it's only a cache.

Fixed by checking if the object is unmodified; if so we don't need to
try to repopulate it. This does add an additional checksum to the unlock
path, but it's already checksumming the worktree file in another case,
so it doesn't slow it down overall.

Further investigation found a similar problem occurred when smudge --clean
is called on a file and the inode cache is not populated. cleanOldKeys
deleted the unmodified old object file in this case. This was also
fixed by checking if the object is unmodified.

In general, use of getInodeCaches and sameInodeCache is potentially
dangerous if the inode cache has not gotten populated for some reason.
Better to use isUnmodified. I breifly auited other places that check the
inode cache, and did not see any immediate problems, but it would be easy
to miss this kind of problem.

original whining

added meta for myself

initial suggestion

Git Annex Assistant occasionally replaces files with dangling symlinks.

Added a comment: Dumb old me....

Added a comment

Added a comment: git-annex-undo removes files, possibly destroying information? Please explain.

fix typo

Merge branch 'master' of ssh://git-annex.branchable.com

comment

Added a comment: real happy about optimisations!

add news item for git-annex 6.20161012

releasing package git-annex version 6.20161012

Added a comment

Merge branch 'master' of ssh://git-annex.branchable.com

devblog

fix tree graft-in bug

When adding a tree like a/b/c/d when a/b already exists, fixes the bug that
the tree that got created was a/b/a/b/c/d

Just need to flatten out the top N directories of the tree that's being
grafted in, so we get the c/d part. This was complicated by the Tree
data type being a rose tree rather than a regular tree.

This commit was sponsored by Nick Daly on Patreon.

add test case for sync_in_adjusted_branch_deleted_recently_added_files

This commit was sponsored by Denis Dzyubenko on Patreon.

Added a comment: related work

devblog

sync: Fix bug in adjusted branch merging that could cause recently added files to be lost when updating the adjusted branch.

The modification flag was not being set when making modifications deep
in a tree, so parent trees were not updated to contain the modified tree.

Seems to have exposed another bug where the wrong filename gets grafted in.

This commit was sponsored by Brock Spratlen on Patreon.

more analysis

reproduce recipe

Added a comment: Build on Debian 7.11 AMD64

Move the env description to the right place

Added a comment: Workflow Summary

Added a comment

Reporting missing file in locally installed doc causing reduced reading comfort.

Added a comment: Compression level

Added a comment

rename forum/bittorrent__58___support_offline_operation_and_verification.mdwn to todo/bittorrent__58___support_offline_operation_and_verification.mdwn

suggest bittorrent enhancements

Added a comment

Added a comment: Re: attaching a torrent file to a downloaded and annexed directory

Added a comment: 780 source files....

Added a comment

Added a comment

devblog

response

comment

Support using v3 repositories without upgrading them to v5.

An easy change now that supportedVersions is a list. Since v3 and v5 are
identical other than version number, just add v3 to the list.

This commit was sponsored by andrea rota.

When auto-upgrading a v3 remote, avoid upgrading to version 6, instead keep it at version 5.

Fixes a bug introduced with v6 mode that I didn't notice until now.
Probably not many v3 repos left out there, and upgrading them to v6 mode
is not disastrous, only a little premature.

This commit was sponsored by Riku Voipio

verified fix on OSX

comment

moreinfo

response

Avoid using a lot of memory when large objects are present in the git repository

.. and have to be checked to see if they are a pointed to an annexed file.

Cases where such memory use could occur included, but were not limited to:
  - git commit -a of a large unlocked file (in v5 mode)
  - git-annex adjust when a large file was checked into git directly
Generally, any use of catKey was a potential problem.

Fix by using git cat-file --batch-check to check size before catting.
This adds another git batch process, which is included in the CatFileHandle
for simplicity.

There could be performance impact, anywhere catKey is used. Particularly
likely to affect adjusted branch generation speed, and operations on
unlocked files in v6 mode. Hopefully since the --batch-check and
--batch read the same data, disk buffering will avoid most overhead.
Leaving only the overhead of talking to the process over the pipe and
whatever computation --batch-check needs to do.

This commit was sponsored by Bruno BEAUFILS on Patreon.

add missing case for unknown size with normal output

This was lost in previous change, causing a crash in that case.

comment

moreinfo

comments

Merge branch 'master' of ssh://git-annex.branchable.com

remove localedir file, fix build

Added a comment: bittorrent

Added a comment

Linux standalone: Include locale files in the bundle, and generate locale definition files for the locales in use when starting runshell.

Currently only done for utf-8 locales because the charset can easily be
told for those. Other locales don't include the charset in their name.

The locale definition is generated under git-annex.linux/locales.
So, this only works if the user can write there.

If locale generation fails for any reason, it's silently skipped.

The git-annex-standalone.deb installs the bundle under /usr, so this locale
generation won't work for non-root users.

add LOCPATH to GIT_ANNEX_STANDLONE_ENV

Linux standalone: Add back the LOCPATH=/dev/null hack to avoid the system locale-archive being read.

Version mismatches between the system locale-archive and the glibc in the
bundle have been observed to cause git crashes.

Unfortunately, this causes locales to not be used in the linux standalone
bundle, as was the case until version 6.20160419.

glibc hardcodes the path to /usr/lib/locale/locale-archive and does not
let an environment variable cause a different locale-archive file to be used.

The only other option to include locales in the bundle would be to include
exploded locale definition directories in the bundle for a number of
locales, generated by localedef. But these take at least 300 kb per locale,
and there are a great many locales; it would be hundreds of megabytes to
include them all.

(Hmm, we could include localdef in the bundle, and check LANG in runshell
and compile the locale directories on the fly. This would need
/usr/share/i18n/ and /usr/lib/locale-archive to be included in the bundle.
It's.. doable.)

I know this is going to once again cause users of the bundle to complain
that eg, ls doesn't show their unicode filenames right. Better than strange
crashes though.

comment

response

poll vote (OpenStack SWIFT)

Added a comment: Question

Added a comment: Sketch of implementation, request for comment

How to deal with files that change status from "precious, please keep n copies" to "junk, please delete it from everywhere you find it, now and forever".

Merge branch 'master' of ssh://git-annex.branchable.com

convert TMVars that are never left empty into TVars

This is probably more efficient, and it avoids mistakenly leaving them
empty.

Added a comment: inodes....

Added a comment: Bash on Windows