populate unlocked files with newly available content when ingesting

This can happen when ingesting a new file in either locked or unlocked
mode, when some unlocked files in the repo use the same key, and the
content was not locally available before.

finish v6 support for assistant

Seems to basically work now!

make linkAnnex detect when the file changes as it's being copied/linked in

This fixes a race where the modified file ended up in annex/objects, and
the InodeCache stored in the database was for the modified version, so
git-annex didn't know it had gotten modified.

The race could occur when the smudge filter was running; now it gets the
InodeCache before generating the Key, which avoids the race.

refactoring

no behavior changes

wip v6 support for assistant

Files are not yet added to v6 repos in unlocked mode.

remove (v6) associated file in unannex

Merge branch 'master' into smudge

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

addurl: Added --batch option.

Added a comment

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

Added a comment

Added a comment

Added a comment

Added a comment

Added a comment

Added a comment: A problem with SmartGit then?

Added a comment

fix build warnings under ghc 7.10

Caused by AMP.. Since I've finally upgraded my dev laptop to 7.10,
I may start missing imports that are not needed with it but are with older
versions..

update

reuse comment

comment

comment

comment

comment

comment

comment

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

status: On crippled filesystems, was displaying M for all annexed files that were present. Probably caused by a change to what git status displays in this situation. Fixed by treating files git thinks are modified the same as typechanged files.

add news item for git-annex 5.20151218

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

Added a comment

prep release

interaction with shared clones

Added a comment

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

devblog

update

test suite down to only 4 fails with v6

update todo list

fix docs

"git -a annex.largefiles=* add" cannot be used.. git does not pass the
config along to the smudge filter, sadly.

v6: fix locking modified file when the content is not present

fix add of file that was locked but has been replaced by a new, unlocked file (v6)

fix reversion in v5 git-annex add of unlocked file

In v5, lookupFile is supposed to only look at symlinks on disk (except when
in direct mode).

Note that v6 also has a bug when a locked file's symlink is deleted and is
replaced with a new file. It sees that a link is staged and gets that
key.

temporarily remove cached keys database connection

The problem is that shutdown is not always called, particularly in the test
suite. So, a database connection would be opened, possibly some changes
queued, and then not shut down.

One way this can happen is when using Annex.eval or Annex.run with a new
state. A better fix might be to make both of them call Keys.shutdown
(and be sure to do it even if the annex action threw an error).

Complication: Sometimes they're run reusing an existing state, so shutting
down a database connection could cause problems for other users of that
same state. I think this would need a MVar holding the database handle,
so it could be emptied once shut down, and another user of the database
connection could then start up a new one if it got shut down. But, what if
2 threads were concurrently using the same database handle and one shut it
down while the other was writing to it? Urgh.

Might have to go that route eventually to get the database access to run
fast enough. For now, a quick fix to get the test suite happier, at the
expense of speed.

reorder database shutdown to be concurrency safe

If a DbHandle is in use by another thread, it could be queueing changes
while shutdown is running. So, wait for the worker to finish before
flushing the queue, so that any last-minute writes are included. Before
this fix, they would be silently dropped.

Of course, if the other thread continues to try to use a DbHandle once it's
closed, it will block forever as the worker is no longer reading from the
jobs MVar. So, that would crash with
"thread blocked indefinitely in an MVar operation".

comment

pass --version to init when needed

Merge branch 'master' into smudge

Added a comment

poll vote (My phone (or MP3 player))

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

bring back some deleted functions that git-repair uses

improve temp dir security

http://bugs.debian.org/807341

* Fix insecure temporary permissions when git-annex repair is used in
  in a corrupted git repository.

  Other calls to withTmpDir didn't leak any potentially private data,
  but repair clones the git repository to a temp directory which is made
  using the user's umask. Thus, it might expose a git repo that is
  otherwise locked down.

* Fix potential denial of service attack when creating temp dirs.

  Since withTmpDir used easily predictable temporary directory names,
  an attacker could create foo.0, foo.1, etc and as long as it managed to
  keep ahead of it, could prevent it from ever returning.

  I'd rate this as a low utility DOS attack. Most attackers in a position
  to do this could just fill up the disk /tmp is on to prevent anything
  from writing temp files. And few parts of git-annex use withTmpDir
  anyway, so DOS potential is quite low.

Examined all callers of withTmpDir and satisfied myself that
switching to mkdtmp and so getting a mode 700 temp dir wouldn't break any
of them.

Note that withTmpDirIn continues to not force temp dir to 700.
But it's only used for temp directories inside .git/annex/wherever/
so that is not a problem.

Also re-audited all other uses of temp files and dirs in git-annex.

starting to work on test suite for v6

Use git-annex init --version=6 to get v6 for now

Not ready to make it default because of the direct mode upgrade needing to
all happen at once.

in v6 mode, unannex does not interact badly with pre-commit hook

So can be used in a tree with staged changes, no problems. Much nicer.

recent fsck changes caused ugly message when object was not present

update todo list

implemented upgrade of direct mode repo to v6

reorg

changes for v6 broke fsck in direct mode

clarify

doc update

add: In v6 mode, acts on modified files.

Same as was done in direct mode, except in v6 mode add always adds files
locked, so

fix incorrect doc change

avoid pre-commit check having to do with v5 unlocked files when in v6 mode

rename stuff for v5 unlocked files to indicate it's old

update doc for v6

add: no need to make pass for old unlocked files in v6

have clean filter check if the filename was already in use by an old key

The annex object for it may have been modified due to hard link, and
that should be cleaned up when the new version is added. If another
associated file has the old key's content, that's linked into the annex
object. Otherwise, update location log to reflect that content has been
lost.

add getAssociatedKey

I guess this is just as efficient as the getAssociatedFiles query, but I
have not tried to optimise the database yet.

update inode cache to cover file even when nothing needs to be done to linkAnnex

This covers the case where multiple files have the same content and are
added with git add. Previously only the one that was linked to the annex
got its inode cached; now both are.

todo

Merge branch 'master' into smudge

removed

Added a comment

Added a comment

Added a comment: It worked

Added a comment: I'm also having this issue

Added a comment

Added a comment: Indeed

Added a comment

Added a comment: Repairing ignores disk space issues too

create page

Debian: Build depend on concurrent-output.

In unstable now.

Added a comment

Added a comment

Added a comment

avoid smudge filter returning invalid content

1. git add file
2. git commit
3. modify file
4. git commit
5. git reset HEAD^

Before this fix, that resulted in git saying the file was modified. And
indeed, it didn't have the content it should in the just checked out ref,
because step 3 modified the object file for the old key.

2 more data -> 2 more days

devblog

update

checked getKeysPresent; it's ok for v6 unlocked files

When a v6 unlocked files is removed from the work tree,
unused doesn't show it. When it gets removed from the index,
unused does show it. This is the same as a locked file.

fsck for v6 unlocked files

This only adds 1 stat to each file fscked for locked files, so
added overhead is minimal.

For unlocked files it has to access the database to see if a file
is modified.