| Commit message (Collapse) | Author | Age |
|---|
| | |
|
| | |
|
| |
|
|
|
| |
Avoids an intractable problem that prevents the pre-commit hook from
telling if such a file is intended to be an annexed file or not.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
Getting rid of build warning
warning: 'statfs64' is deprecated: first deprecated in OS X 10.6
[-Wdeprecated-declarations]
10.6 is much older than the oldest git-annex OSX port, so won't break
anything.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Simplify the test suite now that I have a way to setEnv on Windows by not
threading an environement through it.
Incidentially this fixed a failure on Windows, observed when running the
test suite in cygwin terminal, where there is apparently an env var named
"", and it tried to set that when propigating the environment, which failed.
But mostly, it makes the code a lot less horrible.
This commit was sponsored by Rémi Vanicat.
|
| |
|
|
| |
"a:" is an absolute path, so viewedfile test cannot be run on it.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I have a theory that something is deleting the .t directory
or it doesn't get made in the location tried.
The last test showed:
add: ("recordedInodeCache",Key {keyName = "e394a389d787383843decc5d3d99b6d184ffa5fddeec23b911f9ee7fc8b9ea77", keyBackendName = "SHA256E", keySize = Just 20, keyMtime = Nothing, keyChunkSize = Nothing, keyChunkNum = Nothing},"start")
("recordedInodeCache",Key {keyName = "e394a389d787383843decc5d3d99b6d184ffa5fddeec23b911f9ee7fc8b9ea77", keyBackendName = "SHA256E", keySize = Just 20, keyMtime = Nothing, keyChunkSize = Nothing, keyChunkNum = Nothing},"end")
("writeInodeCache",Key {keyName = "e394a389d787383843decc5d3d99b6d184ffa5fddeec23b911f9ee7fc8b9ea77", keyBackendName = "SHA256E", keySize = Just 20, keyMtime = Nothing, keyChunkSize = Nothing, keyChunkNum = Nothing},"start")
git-annex: c:\jenkins\workspace\msysgit-git-annex-assistant-test\git-annex\.t\repo\.git\annex\objects\6cd\e82\SHA256E-s20--e394a389d787383843decc5d3d99b6d184ffa5fddeec23b911f9ee7fc8b9ea77\SHA256E-s20--e394a389d787383843decc5d3d99b6d184ffa5fddeec23b911f9ee7fc8b9ea77.cache: openFile: does not exist (No such file or directory)
FAIL
add failed
So writeInodeCache is what's failing, and it seems to fail to write the file
despite having made the parent directory.
|
| |
|
|
| |
This reverts commit 59956b117da3070cc0d66e997ff3b318fb6153d4.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
More aggressive rsync params fixup for windows. Param may contain a url, or
a file path, so check if it looks like a local file path and if so, fix it
up.
On windows only, rsyncUrlIsPath will treat c:foo as a path, rather than as
a rsyncurl starting with a host "c".
|
| | |
|
| | |
|
| |\ |
|
| | | |
|
| |/ |
|
| |
|
|
|
| |
Fixes:
/home/joey/tmp/xxx/.git/annex/misctmp/torrent18347: openFile: resource busy (file is locked)
|
| |\ |
|
| | |
| |
| |
| |
| | |
Amoung other fixes, this means that addurl will stage added files even if
adding one of the urls fails.
|
| | | |
|
| | | |
|
| | | |
|
| |/ |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
strangely only OSX noticed this was imported and unused
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The url log could have an url for a key, while the location log thinks it's
not present in the web. In this case, addurl --file url would not do
anything. Fixed it to re-add the web as a location.
I don't know how this situation could arise, but I saw it in the wild in
the conference_proceedings repo, affecting key
URL-s17806003--http://mirror.linux.org.au/pub/linux.conf.au/2014/Wednesday/53-Building_Effective_Alliances_around_the_Trans-Pacific_Partnershi-c0505b631127ccc67e38e637344d988e
Investigating the presence log, it looked like that key
was originally listed as present in the web, then in commit
56abf9e9f3e691ed9d83513037d4019313321ca3 someone else's git-annex
set it and some other things to not present in the web. It would be
interesting to know what that user did, but I doubt I'll be able to find
out. All I can tell from this investigation is that the inconsistency was
not introduced when originally addurl-ing the url.
|
| | |
|
https://www.google.com/accounts/o8/id?id=AItOawm0ZGPYdW9X-QpH6ACBTrKCCAd8qyRX35g
Joey Hess
https://openid.stackexchange.com/user/3ee5cf54-f022-4a71-8666-3c2b5ee231dd
https://www.google.com/accounts/o8/id?id=AItOawm_r8eXWWVKgrz6PO8yiYhWQxMOYyEHYhE
Philipp
gernot
https://www.google.com/accounts/o8/id?id=AItOawkev8_Er652-NMvfEpn3r5VwulP5phjNuI
https://id.koumbit.net/anarcat