| Commit message (Collapse) | Author | Age |
|---|
| ... | |
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Avoid crashing when "git annex get" fails to download from one location,
and falls back to downloading from a second location.
The problem is that git annex get calls download recursively from within
itself if the first download attempt fails. So the first time through, it
writes a transfer info file, which is then overwritten on the second,
recursive call. Then on cleanup, it tries to delete the file twice, which
of course doesn't work.
Fixed both by not crashing if the transfer file is removed, and by
changing Get to not run download recursively like that. It's the only
thing that did so, and it just seems like a bad idea.
|
| | |
| |
| |
| | |
yowza!!!
|
| | |
| |
| |
| | |
New log file format.
|
| | | |
|
| | |
| |
| |
| |
| |
| | |
This should fix OSX/BSD issues with not noticing transfer information
files with kqueue. Now that threads are used, the thread can manage the
transfer slot allocation and deallocation by itself; much cleaner.
|
| | |
| |
| |
| |
| | |
Also converted its timestand to posix seconds, like is used in the other
log files.
|
| | |
| |
| |
| |
| | |
This seems to happen with kqueue, not inotify. The newly added lck file
triggers an add event and was then parsed as a transfer file.
|
| | | |
|
| | |
| |
| |
| |
| | |
foo.lck could be a lock file for a transfer of foo, or a transfer of a key
that happened to end in ".lck". Fix this by using "lck.foo" instead.
|
| | |
| |
| |
| |
| |
| |
| | |
Since the lock file has to be kept open, this prevented the TransferWatcher
from noticing when it appeared, since inotify (and more importantly kqueue)
events happen when a new file is closed. Writing a separate info file fixes
that problem.
|
| | |
| |
| |
| |
| |
| | |
There's still a bug; if the child updates its transfer info file,
then the data from it will superscede the TransferInfo, losing the
info that we should wait on this child.
|
| | | |
|
| | |
| |
| |
| | |
finally!
|
| | |
| |
| |
| | |
This changes the file format.
|
| |/
|
|
| |
This changes the file format.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
Not yet tested and places git-annex-shell is run need to be modified to
pass the new field settings.
Note that rsyncServerSend was changed to fork, rather than directly exec
rsync, because it needs to keep the transfer lock held, and clean up the
transfer log when done.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In order to record a semi-useful filename associated with the key,
this required plumbing the filename all the way through to the remotes'
storeKey and retrieveKeyFile.
Note that there is potential for deadlock here, narrowly avoided.
Suppose the repos are A and B. A sends file foo to B, and at the same
time, B gets file foo from A. So, A locks its upload transfer info file,
and then locks B's download transfer info file. At the same time,
B is taking the two locks in the opposite order. This is only not a
deadlock because the lock code does not wait, and aborts. So one of A or
B's transfers will be aborted and the other transfer will continue.
Whew!
|
| |
|
|
|
|
| |
fdToHandle seems to close the fd
avoid excess trailing newline
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Although I hate to lose one of the only places I've ever used the list monad..
|
| |
|
|
| |
content into the git repository.
|
| | |
|
| | |
|
| |
|
|
| |
broke a test
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
storing it in remotes/web/xx/yy/foo.log meant lots of extra directory
objects in git. Now I use xx/yy/foo.log.web, which is just as unique, but
more efficient since foo.log is there anyway.
Of course, it still looks in the old location too.
|
| | |
|
| | |
|
| |
|
|
| |
A PITA but worth it to clean up the trust configuration code.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
the trust level of a remote.
This overrides the trust.log, and is overridden by the command-line trust
parameters.
It would have been nicer to have Logs.Trust.trustMap just look up the
configuration for all remotes, but a dependency loop prevented that
(Remotes depends on Logs.Trust in several ways). So instead, look up
the configuration when building remotes, storing it in the same forcetrust
field used for the command-line trust parameters.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
repository they were added to and removed from.
This needs to run git log on the location log files to get at all past
versions of the file, which tends to be a bit slow.
It would be possible to make a version optimised for showing the location
logs for every key. That would only need to run git log once, so would be
faster, but it would need to process an enormous amount of data, so
would not speed up the individual file case.
In the future it would be nice to support log --format. log --json also
doesn't work right yet.
|
| |
|
|
|
| |
Left a few Prelude.head's in where it was checked not null and too hard to
remove, etc.
|
| |
|
|
|
| |
A few were too hard to get rid of, and safe since the code
does check for an empty line.
|
| | |
|
| | |
|
| |
|
|
| |
want git-annex to mention it again.
|
| |
|
|
| |
Signed-off-by: Joey Hess <joey@kitenet.net>
|
| |
|
|
|
| |
Special remotes do not always have a description listed in uuid.log,
and such ones were not listed before.
|
| |
|
|
|
|
|
| |
message, and "git annex version" even works.
Things that sound simple, but are made hard by the Annex monad being built
with the assumption that there will always be a git repo.
|
| |
|
|
|
|
| |
semitrusted uuids rarely are listed in trust.log, so a special case
is needed to get a list of them. Take the difference of all known uuids
with non-semitrusted uuids.
|
| |
|
|
| |
3.20111105, whenever the uuid.log is changed (ie, by init or describe).
|
| | |
|
| | |
|
Joey Hess
Mark Wright