Recent comments posted to this site:

I can't seem to change the name of the bug to something more appropriate. Maybe you can?

Comment by Hans_Ryding Thu Aug 21 09:14:16 2014

Incorrect assumption from my part. I reinstalled git into the expected path (C:\program files\Git) and the problem is still there.

Running git-annex from command-line works. (I tried running git-annex test. It had 23 failed tests, most of them because of inability to access the remote: origin. But it ran just fine.) Running the web-app gives the error listed above.

Comment by Hans_Ryding Thu Aug 21 08:54:50 2014

Just an FYI: I tried to "cabal install --only-dependencies" with GHC 7.8 and it fails because DAV-1.0.1 is pulling in lens-3.10.3 which is not compatible with GHC 7.8 due to changes in Typeable.

I don't have enough experience with cabal to figure out why it's not trying to use a newer version of lens.

Comment by Edward Wed Aug 20 20:06:01 2014
git-annex does not hardcode any paths, and certianly not the path to git. Your system probably does not have the location you installed git added to the PATH. In that case, git-annex may do what windows programs do and look for git.exe in the same directory it was installed into.
Comment by joeyh.name Wed Aug 20 14:37:30 2014

https://mega.co.nz/#!HYZmwSIb!gCd9jvVIyYye_bpsUq_vuEed4g7NTlEl2xDRheE1Lx4

This is the log of git annex repair --debug.

Comment by jg123h12jh3y12g3y Wed Aug 20 05:49:02 2014

Brew doesn't include git-remote-gcrypt, so I installed your fork of it manually. That works well and if you use a symlink to include it in the PATH you can easily update (pull) the repo. If one can install git-remote-gcrypt using brew, I don't know how.

Best, Jean-Louis

Comment by Ganwell Tue Aug 19 21:54:16 2014

Hi,

Would it be hard to handle the wildcard character in the location view before the = sign.

git annex foo/=*

works but

git annex *=/bar

does not.

Comment by Samuel Tue Aug 19 06:11:50 2014

True of a single filesystem, but not of a set of connected git repositories.

That’s a good point. Might depend on the use case, though.

The probabilities of these seem low, but perhaps not as low as the probability that there will be two differing files with the same name+size+mtime in the first place.

This one I’m not completely sure about. E.g., I have an annex with web pages mirrored from the web. Due to the crawler implementation, there are lots of «index.html» or «favicon.ico» with the same mtime (in particular when mtime is read with a 1 sec. precision). Files like favicon are often bitmaps of the same resolution and often have the same size due to this. Because there are file-formats where both size and basename are semantically pre-determined, there is zero entropy from these sources alone (also cf. «readme.txt»). The entropy of mtime alone is not really large, I suppose, and in some use-cases will also approach zero (think «initializing a repo by cp -r on a fast disk without preserving mtime). The relative path could make a huge difference there. I believe this argument is actually what worried me the most. Does it seem valid?

Apart from entropy, there’s the non-probabilistic advantage we discussed (granted, with some limiting constraints which one has to assure for oneself). Granted, one might argue a hash would be the better way, but this is not always practical in every setup.

Comment by zardoz Mon Aug 18 20:54:10 2014

Rather than saying that the relative path adds additional entropy, what I was aiming at is the file-system cannot have two alternate versions of one file name at the same path with the same mtime

True of a single filesystem, but not of a set of connected git repositories. :)

So there are multiple scenarios when encoding the file path in the key doesn't help. The probabilities of these seem low, but perhaps not as low as the probability that there will be two differing files with the same name+size+mtime in the first place. It's not clear to me that it adds more than a false sense of security to change from basename to git filename.

Comment by joeyh.name Mon Aug 18 18:39:33 2014
Ah, well then, that sounds a lot more reasonable. Though legal, I have yet to hear of a sane reason for using newlines in filenames.
Comment by EskildHustvedt Sat Aug 16 15:22:35 2014