| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
| |
The Utility.PID will clean up other code soon.
|
| |
|
|
|
|
| |
Potentially fixes some FD leak if an action on an opened file handle fails
for some reason. There have been some hard to reproduce reports of
git-annex leaking FDs, and this may solve them.
|
| | |
|
| |
|
|
| |
This is all the easy cases, where there was already a separate lock file.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
Fixed up a number of things that had worked around there not being a way to
get that.
Most notably, transfer info files on windows now include the process id,
since no locking is currently done. This means the file format varies
between windows and unix.
|
| |
|
|
|
|
|
|
| |
Windows has a larger (unsigned) PID space, so cannot use the unix CInt
there.
Note that TransferInfo does not yet ever get the TransferPid populated,
as there is missing locking.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
scan. This prevents repeated retries to download files that are not available, or are not referenced by the current git tree.
This is motivated by a user report that the assistant was repeatedly
retrying transfers of files that had been deleted (in direct mode, so
removing the only copy).
Note that the glacier code retries failed transfers after a while to retry
downloads that have aged long enough to be available. This is ok; if we're
doing a full transfer scan we'll retry on every file that is still in the
git tree.
Also note that this makes the assistant less likely to get every file
referenced by old revs of the git tree. Not something the assistant tries
to ensure anyway, so I feel this is acceptable.
|
| | |
|
| |
|
|
|
| |
The latter is harder for me to remember, but avoids build failures in code
used by the configure program.
|
| | |
|
| |
|
|
| |
next file, rather than dying.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
Made fromDirect check that a file in the tree has good content (and is not
a broken symlink either) before copying it to another file that has the
same key.
Made replaceFile clean up the temp file if the action that creates it, or
the file replacement action fails.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Most remotes have meters in their implementations of retrieveKeyFile
already. Simply hooking these up to the transfer log makes that information
available. Easy peasy.
This is particularly valuable information for encrypted remotes, which
otherwise bypass the assistant's polling of temp files, and so don't have
good progress bars yet.
Still some work to do here (see progressbars.mdwn changes), but this
is entirely an improvement from the lack of progress bars for encrypted
downloads.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
There was confusion in different parts of the progress bar code about
whether an update contained the total number of bytes transferred, or the
number of bytes transferred since the last update. One way this bug
showed up was progress bars that seemed to stick at zero for a long time.
In order to fix it comprehensively, I add a new BytesProcessed data type,
that is explicitly a total quantity of bytes, not a delta.
Note that this doesn't necessarily fix every problem with progress bars.
Particularly, buffering can now cause progress bars to seem to run ahead
of transfers, reaching 100% when data is still being uploaded.
|
| |
|
|
| |
already in progress, rather than failing with no indication why.
|
| |
|
|
|
|
| |
Rather than forking a git-annex transferkey only to have it fail,
just immediately record the failed transfer (so when the drive is plugged
in, the scan will retry it).
|
| | |
|
| | |
|
| |
|
|
| |
This is possible now that we build-depend on QuickCheck.
|
| |
|
|
| |
and the code gets better..
|
| |
|
|
| |
Fixed a bug the quickcheck turned up.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The newline after the filename was included in it.
This was generally benign -- mostly these filenames are just displayed,
and the newline didn't matter.
But in the assistant, it caused unexpected dropping of preferred
content.
A characteristic of this bug is that the drop was displayed like this:
drop some_file
ok
|
| | |
|
| |
|
|
|
| |
This used to work, but got broken when the transfer info files were added,
as it failed writing them on the readonly filesystem.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
Fix resuming of downloads, which do not have a transfer info file to read.
When checking upload progress, use the MVar, rather than re-reading
the info file.
Catch exceptions in the transfer action. Required a tryAnnex.
|
| |
|
|
|
|
|
| |
When a transfer fails, the progress info can be used to intelligently
retry it. If the transfer managed to make some progress, but did not
fully complete, then there's a good chance that a retry will finish it
(or at least make more progress).
|
| |
|
|
|
| |
TODO: Use this when running sendkey, to feed back transfer info from the
client side rsync.
|
| |
|
|
| |
transferred
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
Transfer info files are updated when the callback is called, updating
the number of bytes transferred.
Left unused p variables at every place the callback should be used.
Which is rather a lot..
|
| |
|
|
| |
And add a form to add another, unrelated repository
|
| | |
|
| | |
|
| |
|
|
| |
files and reading from checksum commands.
|
| | |
|
| | |
|
| |
|
|
|
| |
Change alterTransferInfo to not merge in old values, including
transferPaused.
|
| |
|
|
| |
bytesComplete value
|
| |
|
|
| |
Doesn't fix the bug I thought it'd fix, but is clearly correct.
|
| |
|
|
|
| |
Since it turned out to make sense to always scan all remotes on startup,
there's no need to persist the info about which have been scanned.
|
Joey Hess
Joey Hess