2012-11-16 21:58:08 +00:00
|
|
|
{- git-annex chunked remotes
|
|
|
|
-
|
2020-01-13 16:35:39 +00:00
|
|
|
- Copyright 2014-2020 Joey Hess <id@joeyh.name>
|
2012-11-16 21:58:08 +00:00
|
|
|
-
|
2019-03-13 19:48:14 +00:00
|
|
|
- Licensed under the GNU AGPL version 3 or higher.
|
2012-11-16 21:58:08 +00:00
|
|
|
-}
|
|
|
|
|
2014-07-27 00:11:41 +00:00
|
|
|
module Remote.Helper.Chunked (
|
|
|
|
ChunkSize,
|
|
|
|
ChunkConfig(..),
|
2015-08-19 18:13:19 +00:00
|
|
|
noChunks,
|
2014-10-21 18:36:09 +00:00
|
|
|
describeChunkConfig,
|
2020-01-14 17:18:15 +00:00
|
|
|
chunkConfigParsers,
|
2014-08-03 19:35:23 +00:00
|
|
|
getChunkConfig,
|
2014-07-27 00:11:41 +00:00
|
|
|
storeChunks,
|
|
|
|
removeChunks,
|
|
|
|
retrieveChunks,
|
2014-08-06 17:45:19 +00:00
|
|
|
checkPresentChunks,
|
2020-01-15 15:30:45 +00:00
|
|
|
chunkField,
|
2014-07-27 00:11:41 +00:00
|
|
|
) where
|
2012-11-16 21:58:08 +00:00
|
|
|
|
2016-01-20 20:36:33 +00:00
|
|
|
import Annex.Common
|
2012-11-16 21:58:08 +00:00
|
|
|
import Utility.DataUnits
|
2014-07-29 18:53:17 +00:00
|
|
|
import Types.StoreRetrieve
|
2012-11-16 21:58:08 +00:00
|
|
|
import Types.Remote
|
2020-01-10 18:10:20 +00:00
|
|
|
import Types.ProposedAccepted
|
2014-07-25 20:20:32 +00:00
|
|
|
import Logs.Chunk
|
2014-07-24 20:42:35 +00:00
|
|
|
import Utility.Metered
|
2014-07-27 00:11:41 +00:00
|
|
|
import Crypto (EncKey)
|
2014-07-30 14:34:39 +00:00
|
|
|
import Backend (isStableKey)
|
2019-10-10 20:10:12 +00:00
|
|
|
import Annex.SpecialRemote.Config
|
2012-11-16 21:58:08 +00:00
|
|
|
|
2014-07-24 20:42:35 +00:00
|
|
|
import qualified Data.ByteString.Lazy as L
|
2012-11-16 21:58:08 +00:00
|
|
|
|
2014-07-24 18:49:22 +00:00
|
|
|
data ChunkConfig
|
|
|
|
= NoChunks
|
2014-07-24 19:08:07 +00:00
|
|
|
| UnpaddedChunks ChunkSize
|
|
|
|
| LegacyChunks ChunkSize
|
2014-08-01 19:36:11 +00:00
|
|
|
deriving (Show)
|
2012-11-16 21:58:08 +00:00
|
|
|
|
2014-10-21 18:36:09 +00:00
|
|
|
describeChunkConfig :: ChunkConfig -> String
|
|
|
|
describeChunkConfig NoChunks = "none"
|
|
|
|
describeChunkConfig (UnpaddedChunks sz) = describeChunkSize sz ++ "chunks"
|
|
|
|
describeChunkConfig (LegacyChunks sz) = describeChunkSize sz ++ " chunks (old style)"
|
|
|
|
|
|
|
|
describeChunkSize :: ChunkSize -> String
|
|
|
|
describeChunkSize sz = roughSize storageUnits False (fromIntegral sz)
|
|
|
|
|
2014-07-27 06:13:51 +00:00
|
|
|
noChunks :: ChunkConfig -> Bool
|
|
|
|
noChunks NoChunks = True
|
|
|
|
noChunks _ = False
|
|
|
|
|
2020-01-14 17:18:15 +00:00
|
|
|
chunkConfigParsers :: [RemoteConfigFieldParser]
|
|
|
|
chunkConfigParsers =
|
2020-01-20 19:20:04 +00:00
|
|
|
[ optionalStringParser chunksizeField HiddenField -- deprecated
|
2020-01-14 16:35:08 +00:00
|
|
|
, optionalStringParser chunkField
|
2020-01-20 19:20:04 +00:00
|
|
|
(FieldDesc "size of chunks (eg, 1MiB)")
|
2020-01-13 16:35:39 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
getChunkConfig :: ParsedRemoteConfig -> ChunkConfig
|
|
|
|
getChunkConfig c =
|
|
|
|
case getRemoteConfigValue chunksizeField c of
|
|
|
|
Nothing -> case getRemoteConfigValue chunkField c of
|
2014-07-24 18:49:22 +00:00
|
|
|
Nothing -> NoChunks
|
2020-01-14 17:05:38 +00:00
|
|
|
Just v -> readsz UnpaddedChunks v chunkField
|
|
|
|
Just v -> readsz LegacyChunks v chunksizeField
|
2013-10-26 19:03:12 +00:00
|
|
|
where
|
2020-01-13 16:35:39 +00:00
|
|
|
readsz mk v f = case readSize dataUnits v of
|
2014-08-01 19:36:11 +00:00
|
|
|
Just size
|
|
|
|
| size == 0 -> NoChunks
|
2020-01-13 16:35:39 +00:00
|
|
|
| size > 0 -> mk (fromInteger size)
|
2020-01-10 18:10:20 +00:00
|
|
|
_ -> giveup $ "bad configuration " ++ fromProposedAccepted f ++ "=" ++ v
|
2014-07-24 20:42:35 +00:00
|
|
|
|
2014-07-25 20:20:32 +00:00
|
|
|
-- An infinite stream of chunk keys, starting from chunk 1.
|
|
|
|
newtype ChunkKeyStream = ChunkKeyStream [Key]
|
|
|
|
|
|
|
|
chunkKeyStream :: Key -> ChunkSize -> ChunkKeyStream
|
|
|
|
chunkKeyStream basek chunksize = ChunkKeyStream $ map mk [1..]
|
|
|
|
where
|
2019-11-22 20:24:04 +00:00
|
|
|
mk chunknum = alterKey sizedk $ \d -> d
|
|
|
|
{ keyChunkNum = Just chunknum }
|
|
|
|
sizedk = alterKey basek $ \d -> d
|
|
|
|
{ keyChunkSize = Just (toInteger chunksize) }
|
2014-07-25 20:20:32 +00:00
|
|
|
|
|
|
|
nextChunkKeyStream :: ChunkKeyStream -> (Key, ChunkKeyStream)
|
|
|
|
nextChunkKeyStream (ChunkKeyStream (k:l)) = (k, ChunkKeyStream l)
|
2015-04-19 04:38:29 +00:00
|
|
|
nextChunkKeyStream (ChunkKeyStream []) = error "expected infinite ChunkKeyStream"
|
2014-07-25 20:20:32 +00:00
|
|
|
|
|
|
|
takeChunkKeyStream :: ChunkCount -> ChunkKeyStream -> [Key]
|
|
|
|
takeChunkKeyStream n (ChunkKeyStream l) = genericTake n l
|
|
|
|
|
|
|
|
-- Number of chunks already consumed from the stream.
|
|
|
|
numChunks :: ChunkKeyStream -> Integer
|
2019-11-22 20:24:04 +00:00
|
|
|
numChunks = pred . fromJust . fromKey keyChunkNum . fst . nextChunkKeyStream
|
2014-07-25 20:20:32 +00:00
|
|
|
|
2014-07-26 16:04:35 +00:00
|
|
|
{- Splits up the key's content into chunks, passing each chunk to
|
|
|
|
- the storer action, along with a corresponding chunk key and a
|
|
|
|
- progress meter update callback.
|
2014-07-25 20:20:32 +00:00
|
|
|
-
|
resume interrupted chunked uploads
Leverage the new chunked remotes to automatically resume uploads.
Sort of like rsync, although of course not as efficient since this
needs to start at a chunk boundry.
But, unlike rsync, this method will work for S3, WebDAV, external
special remotes, etc, etc. Only directory special remotes so far,
but many more soon!
This implementation will also allow starting an upload from one repository,
interrupting it, and then resuming the upload to the same remote from
an entirely different repository.
Note that I added a comment that storeKey should atomically move the content
into place once it's all received. This was already an undocumented
requirement -- it's necessary for hasKey to work reliably. This resume code
just uses hasKey to find the first chunk that's missing.
Note that if there are two uploads of the same key to the same chunked remote,
one might resume at the point the other had gotten to, but both will then
redundantly upload. As before.
In the non-resume case, this adds one hasKey call per storeKey, and only
if the remote is configured to use chunks. Future work: Try to eliminate that
hasKey. Notice that eg, `git annex copy --to` checks if the key is present
before sending it, so is already running hasKey.. which could perhaps
be cached and reused.
However, this additional overhead is not very large compared with
transferring an entire large file, and the ability to resume
is certianly worth it. There is an optimisation in place for small files,
that avoids trying to resume if the whole file fits within one chunk.
This commit was sponsored by Georg Bauer.
2014-07-28 18:18:08 +00:00
|
|
|
- To support resuming, the checker is used to find the first missing
|
|
|
|
- chunk key. Storing starts from that chunk.
|
|
|
|
-
|
2014-07-27 05:18:38 +00:00
|
|
|
- This buffers each chunk in memory, so can use a lot of memory
|
|
|
|
- with a large ChunkSize.
|
|
|
|
- More optimal versions of this can be written, that rely
|
|
|
|
- on L.toChunks to split the lazy bytestring into chunks (typically
|
|
|
|
- smaller than the ChunkSize), and eg, write those chunks to a Handle.
|
|
|
|
- But this is the best that can be done with the storer interface that
|
|
|
|
- writes a whole L.ByteString at a time.
|
2014-07-25 20:20:32 +00:00
|
|
|
-}
|
2014-07-27 03:26:10 +00:00
|
|
|
storeChunks
|
|
|
|
:: UUID
|
|
|
|
-> ChunkConfig
|
2016-04-27 16:54:43 +00:00
|
|
|
-> EncKey
|
2014-07-27 03:26:10 +00:00
|
|
|
-> Key
|
|
|
|
-> FilePath
|
|
|
|
-> MeterUpdate
|
2014-08-06 17:45:19 +00:00
|
|
|
-> Storer
|
|
|
|
-> CheckPresent
|
2020-05-13 18:03:00 +00:00
|
|
|
-> Annex ()
|
2016-04-27 16:54:43 +00:00
|
|
|
storeChunks u chunkconfig encryptor k f p storer checker =
|
2014-07-29 18:53:17 +00:00
|
|
|
case chunkconfig of
|
2020-10-22 23:54:26 +00:00
|
|
|
-- Only stable keys are safe to store chunked,
|
|
|
|
-- because an unstable key can have multiple different
|
|
|
|
-- objects, and mixing up chunks from them would be
|
|
|
|
-- possible without this check.
|
2020-07-29 19:23:18 +00:00
|
|
|
(UnpaddedChunks chunksize) -> ifM (isStableKey k)
|
|
|
|
( do
|
|
|
|
h <- liftIO $ openBinaryFile f ReadMode
|
|
|
|
go chunksize h
|
|
|
|
liftIO $ hClose h
|
|
|
|
, storer k (FileContent f) p
|
|
|
|
)
|
2014-08-03 20:18:40 +00:00
|
|
|
_ -> storer k (FileContent f) p
|
2014-07-25 20:20:32 +00:00
|
|
|
where
|
2020-05-13 18:03:00 +00:00
|
|
|
go chunksize h = do
|
2014-07-29 18:53:17 +00:00
|
|
|
let chunkkeys = chunkKeyStream k chunksize
|
2016-04-27 16:54:43 +00:00
|
|
|
(chunkkeys', startpos) <- seekResume h encryptor chunkkeys checker
|
2014-07-29 18:53:17 +00:00
|
|
|
b <- liftIO $ L.hGetContents h
|
2014-08-03 20:18:40 +00:00
|
|
|
gochunks p startpos chunksize b chunkkeys'
|
resume interrupted chunked uploads
Leverage the new chunked remotes to automatically resume uploads.
Sort of like rsync, although of course not as efficient since this
needs to start at a chunk boundry.
But, unlike rsync, this method will work for S3, WebDAV, external
special remotes, etc, etc. Only directory special remotes so far,
but many more soon!
This implementation will also allow starting an upload from one repository,
interrupting it, and then resuming the upload to the same remote from
an entirely different repository.
Note that I added a comment that storeKey should atomically move the content
into place once it's all received. This was already an undocumented
requirement -- it's necessary for hasKey to work reliably. This resume code
just uses hasKey to find the first chunk that's missing.
Note that if there are two uploads of the same key to the same chunked remote,
one might resume at the point the other had gotten to, but both will then
redundantly upload. As before.
In the non-resume case, this adds one hasKey call per storeKey, and only
if the remote is configured to use chunks. Future work: Try to eliminate that
hasKey. Notice that eg, `git annex copy --to` checks if the key is present
before sending it, so is already running hasKey.. which could perhaps
be cached and reused.
However, this additional overhead is not very large compared with
transferring an entire large file, and the ability to resume
is certianly worth it. There is an optimisation in place for small files,
that avoids trying to resume if the whole file fits within one chunk.
This commit was sponsored by Georg Bauer.
2014-07-28 18:18:08 +00:00
|
|
|
|
2020-05-13 18:03:00 +00:00
|
|
|
gochunks :: MeterUpdate -> BytesProcessed -> ChunkSize -> L.ByteString -> ChunkKeyStream -> Annex ()
|
resume interrupted chunked uploads
Leverage the new chunked remotes to automatically resume uploads.
Sort of like rsync, although of course not as efficient since this
needs to start at a chunk boundry.
But, unlike rsync, this method will work for S3, WebDAV, external
special remotes, etc, etc. Only directory special remotes so far,
but many more soon!
This implementation will also allow starting an upload from one repository,
interrupting it, and then resuming the upload to the same remote from
an entirely different repository.
Note that I added a comment that storeKey should atomically move the content
into place once it's all received. This was already an undocumented
requirement -- it's necessary for hasKey to work reliably. This resume code
just uses hasKey to find the first chunk that's missing.
Note that if there are two uploads of the same key to the same chunked remote,
one might resume at the point the other had gotten to, but both will then
redundantly upload. As before.
In the non-resume case, this adds one hasKey call per storeKey, and only
if the remote is configured to use chunks. Future work: Try to eliminate that
hasKey. Notice that eg, `git annex copy --to` checks if the key is present
before sending it, so is already running hasKey.. which could perhaps
be cached and reused.
However, this additional overhead is not very large compared with
transferring an entire large file, and the ability to resume
is certianly worth it. There is an optimisation in place for small files,
that avoids trying to resume if the whole file fits within one chunk.
This commit was sponsored by Georg Bauer.
2014-07-28 18:18:08 +00:00
|
|
|
gochunks meterupdate startpos chunksize = loop startpos . splitchunk
|
2014-07-25 20:20:32 +00:00
|
|
|
where
|
2014-07-27 05:18:38 +00:00
|
|
|
splitchunk = L.splitAt chunksize
|
|
|
|
|
|
|
|
loop bytesprocessed (chunk, bs) chunkkeys
|
|
|
|
| L.null chunk && numchunks > 0 = do
|
2014-10-09 18:53:13 +00:00
|
|
|
-- Once all chunks are successfully
|
2014-07-27 05:18:38 +00:00
|
|
|
-- stored, update the chunk log.
|
2014-07-28 17:19:08 +00:00
|
|
|
chunksStored u k (FixedSizeChunks chunksize) numchunks
|
2014-07-27 05:18:38 +00:00
|
|
|
| otherwise = do
|
2014-07-30 00:31:16 +00:00
|
|
|
liftIO $ meterupdate' zeroBytesProcessed
|
2014-07-27 05:18:38 +00:00
|
|
|
let (chunkkey, chunkkeys') = nextChunkKeyStream chunkkeys
|
2020-05-13 18:03:00 +00:00
|
|
|
storer chunkkey (ByteContent chunk) meterupdate'
|
|
|
|
let bytesprocessed' = addBytesProcessed bytesprocessed (L.length chunk)
|
|
|
|
loop bytesprocessed' (splitchunk bs) chunkkeys'
|
2014-07-25 20:20:32 +00:00
|
|
|
where
|
2014-07-27 05:18:38 +00:00
|
|
|
numchunks = numChunks chunkkeys
|
2014-10-09 18:53:13 +00:00
|
|
|
{- The MeterUpdate that is passed to the action
|
2014-07-25 20:20:32 +00:00
|
|
|
- storing a chunk is offset, so that it reflects
|
|
|
|
- the total bytes that have already been stored
|
|
|
|
- in previous chunks. -}
|
|
|
|
meterupdate' = offsetMeterUpdate meterupdate bytesprocessed
|
|
|
|
|
resume interrupted chunked uploads
Leverage the new chunked remotes to automatically resume uploads.
Sort of like rsync, although of course not as efficient since this
needs to start at a chunk boundry.
But, unlike rsync, this method will work for S3, WebDAV, external
special remotes, etc, etc. Only directory special remotes so far,
but many more soon!
This implementation will also allow starting an upload from one repository,
interrupting it, and then resuming the upload to the same remote from
an entirely different repository.
Note that I added a comment that storeKey should atomically move the content
into place once it's all received. This was already an undocumented
requirement -- it's necessary for hasKey to work reliably. This resume code
just uses hasKey to find the first chunk that's missing.
Note that if there are two uploads of the same key to the same chunked remote,
one might resume at the point the other had gotten to, but both will then
redundantly upload. As before.
In the non-resume case, this adds one hasKey call per storeKey, and only
if the remote is configured to use chunks. Future work: Try to eliminate that
hasKey. Notice that eg, `git annex copy --to` checks if the key is present
before sending it, so is already running hasKey.. which could perhaps
be cached and reused.
However, this additional overhead is not very large compared with
transferring an entire large file, and the ability to resume
is certianly worth it. There is an optimisation in place for small files,
that avoids trying to resume if the whole file fits within one chunk.
This commit was sponsored by Georg Bauer.
2014-07-28 18:18:08 +00:00
|
|
|
{- Check if any of the chunk keys are present. If found, seek forward
|
|
|
|
- in the Handle, so it will be read starting at the first missing chunk.
|
|
|
|
- Returns the ChunkKeyStream truncated to start at the first missing
|
|
|
|
- chunk, and the number of bytes skipped due to resuming.
|
|
|
|
-
|
|
|
|
- As an optimisation, if the file fits into a single chunk, there's no need
|
|
|
|
- to check if that chunk is present -- we know it's not, because otherwise
|
|
|
|
- the whole file would be present and there would be no reason to try to
|
|
|
|
- store it.
|
|
|
|
-}
|
|
|
|
seekResume
|
|
|
|
:: Handle
|
2016-04-27 16:54:43 +00:00
|
|
|
-> EncKey
|
resume interrupted chunked uploads
Leverage the new chunked remotes to automatically resume uploads.
Sort of like rsync, although of course not as efficient since this
needs to start at a chunk boundry.
But, unlike rsync, this method will work for S3, WebDAV, external
special remotes, etc, etc. Only directory special remotes so far,
but many more soon!
This implementation will also allow starting an upload from one repository,
interrupting it, and then resuming the upload to the same remote from
an entirely different repository.
Note that I added a comment that storeKey should atomically move the content
into place once it's all received. This was already an undocumented
requirement -- it's necessary for hasKey to work reliably. This resume code
just uses hasKey to find the first chunk that's missing.
Note that if there are two uploads of the same key to the same chunked remote,
one might resume at the point the other had gotten to, but both will then
redundantly upload. As before.
In the non-resume case, this adds one hasKey call per storeKey, and only
if the remote is configured to use chunks. Future work: Try to eliminate that
hasKey. Notice that eg, `git annex copy --to` checks if the key is present
before sending it, so is already running hasKey.. which could perhaps
be cached and reused.
However, this additional overhead is not very large compared with
transferring an entire large file, and the ability to resume
is certianly worth it. There is an optimisation in place for small files,
that avoids trying to resume if the whole file fits within one chunk.
This commit was sponsored by Georg Bauer.
2014-07-28 18:18:08 +00:00
|
|
|
-> ChunkKeyStream
|
2014-08-06 17:45:19 +00:00
|
|
|
-> CheckPresent
|
resume interrupted chunked uploads
Leverage the new chunked remotes to automatically resume uploads.
Sort of like rsync, although of course not as efficient since this
needs to start at a chunk boundry.
But, unlike rsync, this method will work for S3, WebDAV, external
special remotes, etc, etc. Only directory special remotes so far,
but many more soon!
This implementation will also allow starting an upload from one repository,
interrupting it, and then resuming the upload to the same remote from
an entirely different repository.
Note that I added a comment that storeKey should atomically move the content
into place once it's all received. This was already an undocumented
requirement -- it's necessary for hasKey to work reliably. This resume code
just uses hasKey to find the first chunk that's missing.
Note that if there are two uploads of the same key to the same chunked remote,
one might resume at the point the other had gotten to, but both will then
redundantly upload. As before.
In the non-resume case, this adds one hasKey call per storeKey, and only
if the remote is configured to use chunks. Future work: Try to eliminate that
hasKey. Notice that eg, `git annex copy --to` checks if the key is present
before sending it, so is already running hasKey.. which could perhaps
be cached and reused.
However, this additional overhead is not very large compared with
transferring an entire large file, and the ability to resume
is certianly worth it. There is an optimisation in place for small files,
that avoids trying to resume if the whole file fits within one chunk.
This commit was sponsored by Georg Bauer.
2014-07-28 18:18:08 +00:00
|
|
|
-> Annex (ChunkKeyStream, BytesProcessed)
|
2016-04-27 16:54:43 +00:00
|
|
|
seekResume h encryptor chunkkeys checker = do
|
resume interrupted chunked uploads
Leverage the new chunked remotes to automatically resume uploads.
Sort of like rsync, although of course not as efficient since this
needs to start at a chunk boundry.
But, unlike rsync, this method will work for S3, WebDAV, external
special remotes, etc, etc. Only directory special remotes so far,
but many more soon!
This implementation will also allow starting an upload from one repository,
interrupting it, and then resuming the upload to the same remote from
an entirely different repository.
Note that I added a comment that storeKey should atomically move the content
into place once it's all received. This was already an undocumented
requirement -- it's necessary for hasKey to work reliably. This resume code
just uses hasKey to find the first chunk that's missing.
Note that if there are two uploads of the same key to the same chunked remote,
one might resume at the point the other had gotten to, but both will then
redundantly upload. As before.
In the non-resume case, this adds one hasKey call per storeKey, and only
if the remote is configured to use chunks. Future work: Try to eliminate that
hasKey. Notice that eg, `git annex copy --to` checks if the key is present
before sending it, so is already running hasKey.. which could perhaps
be cached and reused.
However, this additional overhead is not very large compared with
transferring an entire large file, and the ability to resume
is certianly worth it. There is an optimisation in place for small files,
that avoids trying to resume if the whole file fits within one chunk.
This commit was sponsored by Georg Bauer.
2014-07-28 18:18:08 +00:00
|
|
|
sz <- liftIO (hFileSize h)
|
2019-11-22 20:24:04 +00:00
|
|
|
if sz <= fromMaybe 0 (fromKey keyChunkSize $ fst $ nextChunkKeyStream chunkkeys)
|
resume interrupted chunked uploads
Leverage the new chunked remotes to automatically resume uploads.
Sort of like rsync, although of course not as efficient since this
needs to start at a chunk boundry.
But, unlike rsync, this method will work for S3, WebDAV, external
special remotes, etc, etc. Only directory special remotes so far,
but many more soon!
This implementation will also allow starting an upload from one repository,
interrupting it, and then resuming the upload to the same remote from
an entirely different repository.
Note that I added a comment that storeKey should atomically move the content
into place once it's all received. This was already an undocumented
requirement -- it's necessary for hasKey to work reliably. This resume code
just uses hasKey to find the first chunk that's missing.
Note that if there are two uploads of the same key to the same chunked remote,
one might resume at the point the other had gotten to, but both will then
redundantly upload. As before.
In the non-resume case, this adds one hasKey call per storeKey, and only
if the remote is configured to use chunks. Future work: Try to eliminate that
hasKey. Notice that eg, `git annex copy --to` checks if the key is present
before sending it, so is already running hasKey.. which could perhaps
be cached and reused.
However, this additional overhead is not very large compared with
transferring an entire large file, and the ability to resume
is certianly worth it. There is an optimisation in place for small files,
that avoids trying to resume if the whole file fits within one chunk.
This commit was sponsored by Georg Bauer.
2014-07-28 18:18:08 +00:00
|
|
|
then return (chunkkeys, zeroBytesProcessed)
|
|
|
|
else check 0 chunkkeys sz
|
|
|
|
where
|
|
|
|
check pos cks sz
|
|
|
|
| pos >= sz = do
|
|
|
|
-- All chunks are already stored!
|
|
|
|
liftIO $ hSeek h AbsoluteSeek sz
|
2014-08-01 20:29:39 +00:00
|
|
|
return (cks, toBytesProcessed sz)
|
resume interrupted chunked uploads
Leverage the new chunked remotes to automatically resume uploads.
Sort of like rsync, although of course not as efficient since this
needs to start at a chunk boundry.
But, unlike rsync, this method will work for S3, WebDAV, external
special remotes, etc, etc. Only directory special remotes so far,
but many more soon!
This implementation will also allow starting an upload from one repository,
interrupting it, and then resuming the upload to the same remote from
an entirely different repository.
Note that I added a comment that storeKey should atomically move the content
into place once it's all received. This was already an undocumented
requirement -- it's necessary for hasKey to work reliably. This resume code
just uses hasKey to find the first chunk that's missing.
Note that if there are two uploads of the same key to the same chunked remote,
one might resume at the point the other had gotten to, but both will then
redundantly upload. As before.
In the non-resume case, this adds one hasKey call per storeKey, and only
if the remote is configured to use chunks. Future work: Try to eliminate that
hasKey. Notice that eg, `git annex copy --to` checks if the key is present
before sending it, so is already running hasKey.. which could perhaps
be cached and reused.
However, this additional overhead is not very large compared with
transferring an entire large file, and the ability to resume
is certianly worth it. There is an optimisation in place for small files,
that avoids trying to resume if the whole file fits within one chunk.
This commit was sponsored by Georg Bauer.
2014-07-28 18:18:08 +00:00
|
|
|
| otherwise = do
|
2016-04-27 16:54:43 +00:00
|
|
|
v <- tryNonAsync (checker (encryptor k))
|
resume interrupted chunked uploads
Leverage the new chunked remotes to automatically resume uploads.
Sort of like rsync, although of course not as efficient since this
needs to start at a chunk boundry.
But, unlike rsync, this method will work for S3, WebDAV, external
special remotes, etc, etc. Only directory special remotes so far,
but many more soon!
This implementation will also allow starting an upload from one repository,
interrupting it, and then resuming the upload to the same remote from
an entirely different repository.
Note that I added a comment that storeKey should atomically move the content
into place once it's all received. This was already an undocumented
requirement -- it's necessary for hasKey to work reliably. This resume code
just uses hasKey to find the first chunk that's missing.
Note that if there are two uploads of the same key to the same chunked remote,
one might resume at the point the other had gotten to, but both will then
redundantly upload. As before.
In the non-resume case, this adds one hasKey call per storeKey, and only
if the remote is configured to use chunks. Future work: Try to eliminate that
hasKey. Notice that eg, `git annex copy --to` checks if the key is present
before sending it, so is already running hasKey.. which could perhaps
be cached and reused.
However, this additional overhead is not very large compared with
transferring an entire large file, and the ability to resume
is certianly worth it. There is an optimisation in place for small files,
that avoids trying to resume if the whole file fits within one chunk.
This commit was sponsored by Georg Bauer.
2014-07-28 18:18:08 +00:00
|
|
|
case v of
|
|
|
|
Right True ->
|
|
|
|
check pos' cks' sz
|
|
|
|
_ -> do
|
|
|
|
when (pos > 0) $
|
|
|
|
liftIO $ hSeek h AbsoluteSeek pos
|
|
|
|
return (cks, toBytesProcessed pos)
|
|
|
|
where
|
|
|
|
(k, cks') = nextChunkKeyStream cks
|
2019-11-22 20:24:04 +00:00
|
|
|
pos' = pos + fromMaybe 0 (fromKey keyChunkSize k)
|
resume interrupted chunked uploads
Leverage the new chunked remotes to automatically resume uploads.
Sort of like rsync, although of course not as efficient since this
needs to start at a chunk boundry.
But, unlike rsync, this method will work for S3, WebDAV, external
special remotes, etc, etc. Only directory special remotes so far,
but many more soon!
This implementation will also allow starting an upload from one repository,
interrupting it, and then resuming the upload to the same remote from
an entirely different repository.
Note that I added a comment that storeKey should atomically move the content
into place once it's all received. This was already an undocumented
requirement -- it's necessary for hasKey to work reliably. This resume code
just uses hasKey to find the first chunk that's missing.
Note that if there are two uploads of the same key to the same chunked remote,
one might resume at the point the other had gotten to, but both will then
redundantly upload. As before.
In the non-resume case, this adds one hasKey call per storeKey, and only
if the remote is configured to use chunks. Future work: Try to eliminate that
hasKey. Notice that eg, `git annex copy --to` checks if the key is present
before sending it, so is already running hasKey.. which could perhaps
be cached and reused.
However, this additional overhead is not very large compared with
transferring an entire large file, and the ability to resume
is certianly worth it. There is an optimisation in place for small files,
that avoids trying to resume if the whole file fits within one chunk.
This commit was sponsored by Georg Bauer.
2014-07-28 18:18:08 +00:00
|
|
|
|
2014-07-27 00:11:41 +00:00
|
|
|
{- Removes all chunks of a key from a remote, by calling a remover
|
2014-07-27 02:47:52 +00:00
|
|
|
- action on each.
|
|
|
|
-
|
2014-07-27 00:11:41 +00:00
|
|
|
- This action may be called on a chunked key. It will simply remove it.
|
|
|
|
-}
|
2020-05-14 18:08:09 +00:00
|
|
|
removeChunks :: Remover -> UUID -> ChunkConfig -> EncKey -> Key -> Annex ()
|
2014-07-27 00:11:41 +00:00
|
|
|
removeChunks remover u chunkconfig encryptor k = do
|
2020-10-22 17:37:09 +00:00
|
|
|
ls <- map chunkKeyList <$> chunkKeys u chunkconfig k
|
2020-05-14 18:08:09 +00:00
|
|
|
mapM_ (remover . encryptor) (concat ls)
|
|
|
|
let chunksizes = catMaybes $ map (fromKey keyChunkSize <=< headMaybe) ls
|
|
|
|
forM_ chunksizes $ chunksRemoved u k . FixedSizeChunks . fromIntegral
|
2014-07-27 00:11:41 +00:00
|
|
|
|
2014-07-29 18:53:17 +00:00
|
|
|
{- Retrieves a key from a remote, using a retriever action.
|
2014-07-27 00:11:41 +00:00
|
|
|
-
|
|
|
|
- When the remote is chunked, tries each of the options returned by
|
|
|
|
- chunkKeys until it finds one where the retriever successfully
|
resume interrupted chunked downloads
Leverage the new chunked remotes to automatically resume downloads.
Sort of like rsync, although of course not as efficient since this
needs to start at a chunk boundry.
But, unlike rsync, this method will work for S3, WebDAV, external
special remotes, etc, etc. Only directory special remotes so far,
but many more soon!
This implementation will also properly handle starting a download
from one remote, interrupting, and resuming from another one, and so on.
(Resuming interrupted chunked uploads is similarly doable, although
slightly more expensive.)
This commit was sponsored by Thomas Djärv.
2014-07-27 22:52:42 +00:00
|
|
|
- gets the first chunked key. The content of that key, and any
|
2014-07-27 00:11:41 +00:00
|
|
|
- other chunks in the list is fed to the sink.
|
|
|
|
-
|
|
|
|
- If retrival of one of the subsequent chunks throws an exception,
|
2020-05-13 21:05:56 +00:00
|
|
|
- gives up. Note that partial data may have been written to the sink
|
|
|
|
- in this case.
|
resume interrupted chunked downloads
Leverage the new chunked remotes to automatically resume downloads.
Sort of like rsync, although of course not as efficient since this
needs to start at a chunk boundry.
But, unlike rsync, this method will work for S3, WebDAV, external
special remotes, etc, etc. Only directory special remotes so far,
but many more soon!
This implementation will also properly handle starting a download
from one remote, interrupting, and resuming from another one, and so on.
(Resuming interrupted chunked uploads is similarly doable, although
slightly more expensive.)
This commit was sponsored by Thomas Djärv.
2014-07-27 22:52:42 +00:00
|
|
|
-
|
|
|
|
- Resuming is supported when using chunks. When the destination file
|
|
|
|
- already exists, it skips to the next chunked key that would be needed
|
|
|
|
- to resume.
|
2014-07-27 00:11:41 +00:00
|
|
|
-}
|
|
|
|
retrieveChunks
|
2014-07-29 18:53:17 +00:00
|
|
|
:: Retriever
|
2014-07-27 00:11:41 +00:00
|
|
|
-> UUID
|
|
|
|
-> ChunkConfig
|
|
|
|
-> EncKey
|
|
|
|
-> Key
|
resume interrupted chunked downloads
Leverage the new chunked remotes to automatically resume downloads.
Sort of like rsync, although of course not as efficient since this
needs to start at a chunk boundry.
But, unlike rsync, this method will work for S3, WebDAV, external
special remotes, etc, etc. Only directory special remotes so far,
but many more soon!
This implementation will also properly handle starting a download
from one remote, interrupting, and resuming from another one, and so on.
(Resuming interrupted chunked uploads is similarly doable, although
slightly more expensive.)
This commit was sponsored by Thomas Djärv.
2014-07-27 22:52:42 +00:00
|
|
|
-> FilePath
|
2014-07-27 00:11:41 +00:00
|
|
|
-> MeterUpdate
|
2020-05-13 21:05:56 +00:00
|
|
|
-> (Maybe Handle -> Maybe MeterUpdate -> ContentSource -> Annex ())
|
|
|
|
-> Annex ()
|
resume interrupted chunked downloads
Leverage the new chunked remotes to automatically resume downloads.
Sort of like rsync, although of course not as efficient since this
needs to start at a chunk boundry.
But, unlike rsync, this method will work for S3, WebDAV, external
special remotes, etc, etc. Only directory special remotes so far,
but many more soon!
This implementation will also properly handle starting a download
from one remote, interrupting, and resuming from another one, and so on.
(Resuming interrupted chunked uploads is similarly doable, although
slightly more expensive.)
This commit was sponsored by Thomas Djärv.
2014-07-27 22:52:42 +00:00
|
|
|
retrieveChunks retriever u chunkconfig encryptor basek dest basep sink
|
2014-07-27 06:13:51 +00:00
|
|
|
| noChunks chunkconfig =
|
|
|
|
-- Optimisation: Try the unchunked key first, to avoid
|
resume interrupted chunked downloads
Leverage the new chunked remotes to automatically resume downloads.
Sort of like rsync, although of course not as efficient since this
needs to start at a chunk boundry.
But, unlike rsync, this method will work for S3, WebDAV, external
special remotes, etc, etc. Only directory special remotes so far,
but many more soon!
This implementation will also properly handle starting a download
from one remote, interrupting, and resuming from another one, and so on.
(Resuming interrupted chunked uploads is similarly doable, although
slightly more expensive.)
This commit was sponsored by Thomas Djärv.
2014-07-27 22:52:42 +00:00
|
|
|
-- looking in the git-annex branch for chunk counts
|
|
|
|
-- that are likely not there.
|
unify exception handling into Utility.Exception
Removed old extensible-exceptions, only needed for very old ghc.
Made webdav use Utility.Exception, to work after some changes in DAV's
exception handling.
Removed Annex.Exception. Mostly this was trivial, but note that
tryAnnex is replaced with tryNonAsync and catchAnnex replaced with
catchNonAsync. In theory that could be a behavior change, since the former
caught all exceptions, and the latter don't catch async exceptions.
However, in practice, nothing in the Annex monad uses async exceptions.
Grepping for throwTo and killThread only find stuff in the assistant,
which does not seem related.
Command.Add.undo is changed to accept a SomeException, and things
that use it for rollback now catch non-async exceptions, rather than
only IOExceptions.
2014-08-08 01:55:44 +00:00
|
|
|
getunchunked `catchNonAsync`
|
2020-10-22 16:57:58 +00:00
|
|
|
(\e -> go (Just e) =<< chunkKeysOnly u chunkconfig basek)
|
2020-05-21 18:44:40 +00:00
|
|
|
| otherwise = go Nothing =<< chunkKeys u chunkconfig basek
|
2014-07-27 00:11:41 +00:00
|
|
|
where
|
2020-10-22 17:37:09 +00:00
|
|
|
go pe cks = do
|
|
|
|
let ls = map chunkKeyList cks
|
2020-11-05 15:26:34 +00:00
|
|
|
currsize <- liftIO $ catchMaybeIO $ getFileSize (toRawFilePath dest)
|
resume interrupted chunked downloads
Leverage the new chunked remotes to automatically resume downloads.
Sort of like rsync, although of course not as efficient since this
needs to start at a chunk boundry.
But, unlike rsync, this method will work for S3, WebDAV, external
special remotes, etc, etc. Only directory special remotes so far,
but many more soon!
This implementation will also properly handle starting a download
from one remote, interrupting, and resuming from another one, and so on.
(Resuming interrupted chunked uploads is similarly doable, although
slightly more expensive.)
This commit was sponsored by Thomas Djärv.
2014-07-27 22:52:42 +00:00
|
|
|
let ls' = maybe ls (setupResume ls) currsize
|
2014-08-01 21:18:39 +00:00
|
|
|
if any null ls'
|
2020-05-13 21:05:56 +00:00
|
|
|
then noop -- dest is already complete
|
2020-05-21 18:44:40 +00:00
|
|
|
else firstavail pe currsize ls'
|
2014-07-27 00:11:41 +00:00
|
|
|
|
2020-05-21 18:44:40 +00:00
|
|
|
firstavail Nothing _ [] = giveup "unable to determine the chunks to use for this remote"
|
fix embedcreds=yes reversion
Fix bug that made enableremote of S3 and webdav remotes, that have
embedcreds=yes, fail to set up the embedded creds, so accessing the remotes
failed.
(Regression introduced in version 7.20200202.7 in when reworking all the
remote configs to be parsed.)
Root problem is that parseEncryptionConfig excludes all other config keys
except encryption ones, so it is then unable to find the
credPairRemoteField. And since that field is not required to be
present, it proceeds as if it's not, rather than failing in any visible
way.
This causes it to not find any creds, and so it does not cache
them. When when the S3 remote tries to make a S3 connection, it finds no
creds, so assumes it's being used in no-creds mode, and tries to find a
public url. With no public url available, it fails, but the failure doesn't
say a lack of creds is the problem.
Fix is to provide setRemoteCredPair with a ParsedRemoteConfig, so the full
set of configs of the remote can be parsed. A bit annoying to need to
parse the remote config before the full config (as returned by
setRemoteCredPair) is available, but this avoids the problem.
I assume webdav also had the problem by inspection, but didn't try to
reproduce it with it.
Also, getRemoteCredPair used getRemoteConfigValue to get a ProposedAccepted
String, but that does not seem right. Now that it runs that code, it
crashed saying it had just a String.
Remotes that have already been enableremoted, and so lack the cached creds
file will work after this fix, because getRemoteCredPair will extract
the creds from the remote config, writing the missing file.
This commit was sponsored by Ilya Shlyakhter on Patreon.
2020-05-21 18:34:29 +00:00
|
|
|
firstavail (Just e) _ [] = throwM e
|
|
|
|
firstavail pe currsize ([]:ls) = firstavail pe currsize ls
|
|
|
|
firstavail _ currsize ((k:ks):ls)
|
2014-07-30 00:10:14 +00:00
|
|
|
| k == basek = getunchunked
|
fix embedcreds=yes reversion
Fix bug that made enableremote of S3 and webdav remotes, that have
embedcreds=yes, fail to set up the embedded creds, so accessing the remotes
failed.
(Regression introduced in version 7.20200202.7 in when reworking all the
remote configs to be parsed.)
Root problem is that parseEncryptionConfig excludes all other config keys
except encryption ones, so it is then unable to find the
credPairRemoteField. And since that field is not required to be
present, it proceeds as if it's not, rather than failing in any visible
way.
This causes it to not find any creds, and so it does not cache
them. When when the S3 remote tries to make a S3 connection, it finds no
creds, so assumes it's being used in no-creds mode, and tries to find a
public url. With no public url available, it fails, but the failure doesn't
say a lack of creds is the problem.
Fix is to provide setRemoteCredPair with a ParsedRemoteConfig, so the full
set of configs of the remote can be parsed. A bit annoying to need to
parse the remote config before the full config (as returned by
setRemoteCredPair) is available, but this avoids the problem.
I assume webdav also had the problem by inspection, but didn't try to
reproduce it with it.
Also, getRemoteCredPair used getRemoteConfigValue to get a ProposedAccepted
String, but that does not seem right. Now that it runs that code, it
crashed saying it had just a String.
Remotes that have already been enableremoted, and so lack the cached creds
file will work after this fix, because getRemoteCredPair will extract
the creds from the remote config, writing the missing file.
This commit was sponsored by Ilya Shlyakhter on Patreon.
2020-05-21 18:34:29 +00:00
|
|
|
`catchNonAsync` (\e -> firstavail (Just e) currsize ls)
|
2014-07-30 00:10:14 +00:00
|
|
|
| otherwise = do
|
|
|
|
let offset = resumeOffset currsize k
|
|
|
|
let p = maybe basep
|
|
|
|
(offsetMeterUpdate basep . toBytesProcessed)
|
|
|
|
offset
|
unify exception handling into Utility.Exception
Removed old extensible-exceptions, only needed for very old ghc.
Made webdav use Utility.Exception, to work after some changes in DAV's
exception handling.
Removed Annex.Exception. Mostly this was trivial, but note that
tryAnnex is replaced with tryNonAsync and catchAnnex replaced with
catchNonAsync. In theory that could be a behavior change, since the former
caught all exceptions, and the latter don't catch async exceptions.
However, in practice, nothing in the Annex monad uses async exceptions.
Grepping for throwTo and killThread only find stuff in the assistant,
which does not seem related.
Command.Add.undo is changed to accept a SomeException, and things
that use it for rollback now catch non-async exceptions, rather than
only IOExceptions.
2014-08-08 01:55:44 +00:00
|
|
|
v <- tryNonAsync $
|
2014-07-30 00:10:14 +00:00
|
|
|
retriever (encryptor k) p $ \content ->
|
|
|
|
bracketIO (maybe opennew openresume offset) hClose $ \h -> do
|
2020-05-13 21:05:56 +00:00
|
|
|
tosink (Just h) p content
|
2014-07-30 00:10:14 +00:00
|
|
|
let sz = toBytesProcessed $
|
2019-11-22 20:24:04 +00:00
|
|
|
fromMaybe 0 $ fromKey keyChunkSize k
|
2014-07-30 00:10:14 +00:00
|
|
|
getrest p h sz sz ks
|
|
|
|
case v of
|
|
|
|
Left e
|
2020-05-13 21:05:56 +00:00
|
|
|
| null ls -> throwM e
|
fix embedcreds=yes reversion
Fix bug that made enableremote of S3 and webdav remotes, that have
embedcreds=yes, fail to set up the embedded creds, so accessing the remotes
failed.
(Regression introduced in version 7.20200202.7 in when reworking all the
remote configs to be parsed.)
Root problem is that parseEncryptionConfig excludes all other config keys
except encryption ones, so it is then unable to find the
credPairRemoteField. And since that field is not required to be
present, it proceeds as if it's not, rather than failing in any visible
way.
This causes it to not find any creds, and so it does not cache
them. When when the S3 remote tries to make a S3 connection, it finds no
creds, so assumes it's being used in no-creds mode, and tries to find a
public url. With no public url available, it fails, but the failure doesn't
say a lack of creds is the problem.
Fix is to provide setRemoteCredPair with a ParsedRemoteConfig, so the full
set of configs of the remote can be parsed. A bit annoying to need to
parse the remote config before the full config (as returned by
setRemoteCredPair) is available, but this avoids the problem.
I assume webdav also had the problem by inspection, but didn't try to
reproduce it with it.
Also, getRemoteCredPair used getRemoteConfigValue to get a ProposedAccepted
String, but that does not seem right. Now that it runs that code, it
crashed saying it had just a String.
Remotes that have already been enableremoted, and so lack the cached creds
file will work after this fix, because getRemoteCredPair will extract
the creds from the remote config, writing the missing file.
This commit was sponsored by Ilya Shlyakhter on Patreon.
2020-05-21 18:34:29 +00:00
|
|
|
| otherwise -> firstavail (Just e) currsize ls
|
2014-07-30 00:10:14 +00:00
|
|
|
Right r -> return r
|
resume interrupted chunked downloads
Leverage the new chunked remotes to automatically resume downloads.
Sort of like rsync, although of course not as efficient since this
needs to start at a chunk boundry.
But, unlike rsync, this method will work for S3, WebDAV, external
special remotes, etc, etc. Only directory special remotes so far,
but many more soon!
This implementation will also properly handle starting a download
from one remote, interrupting, and resuming from another one, and so on.
(Resuming interrupted chunked uploads is similarly doable, although
slightly more expensive.)
This commit was sponsored by Thomas Djärv.
2014-07-27 22:52:42 +00:00
|
|
|
|
2020-05-13 21:05:56 +00:00
|
|
|
getrest _ _ _ _ [] = noop
|
resume interrupted chunked downloads
Leverage the new chunked remotes to automatically resume downloads.
Sort of like rsync, although of course not as efficient since this
needs to start at a chunk boundry.
But, unlike rsync, this method will work for S3, WebDAV, external
special remotes, etc, etc. Only directory special remotes so far,
but many more soon!
This implementation will also properly handle starting a download
from one remote, interrupting, and resuming from another one, and so on.
(Resuming interrupted chunked uploads is similarly doable, although
slightly more expensive.)
This commit was sponsored by Thomas Djärv.
2014-07-27 22:52:42 +00:00
|
|
|
getrest p h sz bytesprocessed (k:ks) = do
|
|
|
|
let p' = offsetMeterUpdate p bytesprocessed
|
2014-07-30 00:31:16 +00:00
|
|
|
liftIO $ p' zeroBytesProcessed
|
2020-05-13 21:05:56 +00:00
|
|
|
retriever (encryptor k) p' $ tosink (Just h) p'
|
|
|
|
getrest p h sz (addBytesProcessed bytesprocessed sz) ks
|
resume interrupted chunked downloads
Leverage the new chunked remotes to automatically resume downloads.
Sort of like rsync, although of course not as efficient since this
needs to start at a chunk boundry.
But, unlike rsync, this method will work for S3, WebDAV, external
special remotes, etc, etc. Only directory special remotes so far,
but many more soon!
This implementation will also properly handle starting a download
from one remote, interrupting, and resuming from another one, and so on.
(Resuming interrupted chunked uploads is similarly doable, although
slightly more expensive.)
This commit was sponsored by Thomas Djärv.
2014-07-27 22:52:42 +00:00
|
|
|
|
2014-07-30 00:10:14 +00:00
|
|
|
getunchunked = retriever (encryptor basek) basep $ tosink Nothing basep
|
resume interrupted chunked downloads
Leverage the new chunked remotes to automatically resume downloads.
Sort of like rsync, although of course not as efficient since this
needs to start at a chunk boundry.
But, unlike rsync, this method will work for S3, WebDAV, external
special remotes, etc, etc. Only directory special remotes so far,
but many more soon!
This implementation will also properly handle starting a download
from one remote, interrupting, and resuming from another one, and so on.
(Resuming interrupted chunked uploads is similarly doable, although
slightly more expensive.)
This commit was sponsored by Thomas Djärv.
2014-07-27 22:52:42 +00:00
|
|
|
|
|
|
|
opennew = openBinaryFile dest WriteMode
|
2014-07-27 00:11:41 +00:00
|
|
|
|
resume interrupted chunked downloads
Leverage the new chunked remotes to automatically resume downloads.
Sort of like rsync, although of course not as efficient since this
needs to start at a chunk boundry.
But, unlike rsync, this method will work for S3, WebDAV, external
special remotes, etc, etc. Only directory special remotes so far,
but many more soon!
This implementation will also properly handle starting a download
from one remote, interrupting, and resuming from another one, and so on.
(Resuming interrupted chunked uploads is similarly doable, although
slightly more expensive.)
This commit was sponsored by Thomas Djärv.
2014-07-27 22:52:42 +00:00
|
|
|
-- Open the file and seek to the start point in order to resume.
|
|
|
|
openresume startpoint = do
|
|
|
|
-- ReadWriteMode allows seeking; AppendMode does not.
|
|
|
|
h <- openBinaryFile dest ReadWriteMode
|
|
|
|
hSeek h AbsoluteSeek startpoint
|
|
|
|
return h
|
|
|
|
|
2014-10-09 18:53:13 +00:00
|
|
|
{- Progress meter updating is a bit tricky: If the Retriever
|
2014-07-29 21:17:41 +00:00
|
|
|
- populates a file, it is responsible for updating progress
|
|
|
|
- as the file is being retrieved.
|
|
|
|
-
|
|
|
|
- However, if the Retriever generates a lazy ByteString,
|
|
|
|
- it is not responsible for updating progress (often it cannot).
|
2014-08-03 05:21:38 +00:00
|
|
|
- Instead, the sink is passed a meter to update as it consumes
|
2014-07-30 00:31:16 +00:00
|
|
|
- the ByteString.
|
|
|
|
-}
|
2014-07-30 00:10:14 +00:00
|
|
|
tosink h p content = sink h p' content
|
|
|
|
where
|
|
|
|
p'
|
|
|
|
| isByteContent content = Just p
|
|
|
|
| otherwise = Nothing
|
2014-07-29 21:17:41 +00:00
|
|
|
|
resume interrupted chunked downloads
Leverage the new chunked remotes to automatically resume downloads.
Sort of like rsync, although of course not as efficient since this
needs to start at a chunk boundry.
But, unlike rsync, this method will work for S3, WebDAV, external
special remotes, etc, etc. Only directory special remotes so far,
but many more soon!
This implementation will also properly handle starting a download
from one remote, interrupting, and resuming from another one, and so on.
(Resuming interrupted chunked uploads is similarly doable, although
slightly more expensive.)
This commit was sponsored by Thomas Djärv.
2014-07-27 22:52:42 +00:00
|
|
|
{- Can resume when the chunk's offset is at or before the end of
|
|
|
|
- the dest file. -}
|
|
|
|
resumeOffset :: Maybe Integer -> Key -> Maybe Integer
|
|
|
|
resumeOffset Nothing _ = Nothing
|
|
|
|
resumeOffset currsize k
|
|
|
|
| offset <= currsize = offset
|
|
|
|
| otherwise = Nothing
|
|
|
|
where
|
|
|
|
offset = chunkKeyOffset k
|
|
|
|
|
|
|
|
{- Drops chunks that are already present in a file, based on its size.
|
|
|
|
- Keeps any non-chunk keys.
|
|
|
|
-}
|
|
|
|
setupResume :: [[Key]] -> Integer -> [[Key]]
|
|
|
|
setupResume ls currsize = map dropunneeded ls
|
|
|
|
where
|
|
|
|
dropunneeded [] = []
|
2019-11-22 20:24:04 +00:00
|
|
|
dropunneeded l@(k:_) = case fromKey keyChunkSize k of
|
resume interrupted chunked downloads
Leverage the new chunked remotes to automatically resume downloads.
Sort of like rsync, although of course not as efficient since this
needs to start at a chunk boundry.
But, unlike rsync, this method will work for S3, WebDAV, external
special remotes, etc, etc. Only directory special remotes so far,
but many more soon!
This implementation will also properly handle starting a download
from one remote, interrupting, and resuming from another one, and so on.
(Resuming interrupted chunked uploads is similarly doable, although
slightly more expensive.)
This commit was sponsored by Thomas Djärv.
2014-07-27 22:52:42 +00:00
|
|
|
Just chunksize | chunksize > 0 ->
|
|
|
|
genericDrop (currsize `div` chunksize) l
|
|
|
|
_ -> l
|
2014-07-27 00:11:41 +00:00
|
|
|
|
|
|
|
{- Checks if a key is present in a remote. This requires any one
|
|
|
|
- of the lists of options returned by chunkKeys to all check out
|
|
|
|
- as being present using the checker action.
|
2014-08-06 17:45:19 +00:00
|
|
|
-
|
|
|
|
- Throws an exception if the remote is not accessible.
|
2014-07-27 00:11:41 +00:00
|
|
|
-}
|
2014-08-06 17:45:19 +00:00
|
|
|
checkPresentChunks
|
|
|
|
:: CheckPresent
|
2014-07-27 00:11:41 +00:00
|
|
|
-> UUID
|
|
|
|
-> ChunkConfig
|
|
|
|
-> EncKey
|
|
|
|
-> Key
|
2014-08-06 17:45:19 +00:00
|
|
|
-> Annex Bool
|
|
|
|
checkPresentChunks checker u chunkconfig encryptor basek
|
|
|
|
| noChunks chunkconfig = do
|
2014-07-27 06:13:51 +00:00
|
|
|
-- Optimisation: Try the unchunked key first, to avoid
|
resume interrupted chunked downloads
Leverage the new chunked remotes to automatically resume downloads.
Sort of like rsync, although of course not as efficient since this
needs to start at a chunk boundry.
But, unlike rsync, this method will work for S3, WebDAV, external
special remotes, etc, etc. Only directory special remotes so far,
but many more soon!
This implementation will also properly handle starting a download
from one remote, interrupting, and resuming from another one, and so on.
(Resuming interrupted chunked uploads is similarly doable, although
slightly more expensive.)
This commit was sponsored by Thomas Djärv.
2014-07-27 22:52:42 +00:00
|
|
|
-- looking in the git-annex branch for chunk counts
|
|
|
|
-- that are likely not there.
|
2014-08-06 17:45:19 +00:00
|
|
|
v <- check basek
|
2020-10-22 16:57:58 +00:00
|
|
|
let getchunkkeys = chunkKeysOnly u chunkconfig basek
|
2014-08-06 17:45:19 +00:00
|
|
|
case v of
|
|
|
|
Right True -> return True
|
2020-10-22 16:57:58 +00:00
|
|
|
Left e -> checklists (Just e) =<< getchunkkeys
|
|
|
|
_ -> checklists Nothing =<< getchunkkeys
|
2014-07-29 19:07:32 +00:00
|
|
|
| otherwise = checklists Nothing =<< chunkKeys u chunkconfig basek
|
2014-07-27 00:11:41 +00:00
|
|
|
where
|
2014-08-06 17:45:19 +00:00
|
|
|
checklists Nothing [] = return False
|
2014-08-10 18:52:58 +00:00
|
|
|
checklists (Just deferrederror) [] = throwM deferrederror
|
2020-10-22 17:37:09 +00:00
|
|
|
checklists d (ck:cks)
|
2014-07-27 02:25:50 +00:00
|
|
|
| not (null l) = do
|
|
|
|
v <- checkchunks l
|
|
|
|
case v of
|
2020-10-22 17:37:09 +00:00
|
|
|
Left e -> checklists (Just e) cks
|
|
|
|
Right True -> do
|
|
|
|
ensureChunksAreLogged u basek ck
|
|
|
|
return True
|
|
|
|
Right False -> checklists Nothing cks
|
|
|
|
| otherwise = checklists d cks
|
|
|
|
where
|
|
|
|
l = chunkKeyList ck
|
2014-07-27 00:11:41 +00:00
|
|
|
|
2014-08-10 18:52:58 +00:00
|
|
|
checkchunks :: [Key] -> Annex (Either SomeException Bool)
|
2014-07-27 00:11:41 +00:00
|
|
|
checkchunks [] = return (Right True)
|
|
|
|
checkchunks (k:ks) = do
|
2014-08-06 17:45:19 +00:00
|
|
|
v <- check k
|
|
|
|
case v of
|
|
|
|
Right True -> checkchunks ks
|
|
|
|
Right False -> return $ Right False
|
2014-08-10 18:52:58 +00:00
|
|
|
Left e -> return $ Left e
|
2014-08-06 17:45:19 +00:00
|
|
|
|
unify exception handling into Utility.Exception
Removed old extensible-exceptions, only needed for very old ghc.
Made webdav use Utility.Exception, to work after some changes in DAV's
exception handling.
Removed Annex.Exception. Mostly this was trivial, but note that
tryAnnex is replaced with tryNonAsync and catchAnnex replaced with
catchNonAsync. In theory that could be a behavior change, since the former
caught all exceptions, and the latter don't catch async exceptions.
However, in practice, nothing in the Annex monad uses async exceptions.
Grepping for throwTo and killThread only find stuff in the assistant,
which does not seem related.
Command.Add.undo is changed to accept a SomeException, and things
that use it for rollback now catch non-async exceptions, rather than
only IOExceptions.
2014-08-08 01:55:44 +00:00
|
|
|
check = tryNonAsync . checker . encryptor
|
2014-07-27 00:11:41 +00:00
|
|
|
|
2020-10-22 17:37:09 +00:00
|
|
|
data ChunkKeys
|
|
|
|
= ChunkKeys [Key]
|
|
|
|
| SpeculativeChunkKeys (ChunkMethod, ChunkCount) [Key]
|
|
|
|
|
|
|
|
chunkKeyList :: ChunkKeys -> [Key]
|
|
|
|
chunkKeyList (ChunkKeys l) = l
|
|
|
|
chunkKeyList (SpeculativeChunkKeys _ l) = l
|
|
|
|
|
2014-07-27 05:24:34 +00:00
|
|
|
{- A key can be stored in a remote unchunked, or as a list of chunked keys.
|
2014-07-27 06:13:51 +00:00
|
|
|
- This can be the case whether or not the remote is currently configured
|
|
|
|
- to use chunking.
|
|
|
|
-
|
|
|
|
- It's even possible for a remote to have the same key stored multiple
|
|
|
|
- times with different chunk sizes!
|
|
|
|
-
|
|
|
|
- This finds all possible lists of keys that might be on the remote that
|
|
|
|
- can be combined to get back the requested key, in order from most to
|
|
|
|
- least likely to exist.
|
2020-10-22 16:57:58 +00:00
|
|
|
-
|
|
|
|
- Speculatively tries chunks using the ChunkConfig last of all
|
|
|
|
- (when that's not the same as the recorded chunks). This can help
|
|
|
|
- recover from data loss, where the chunk log didn't make it out,
|
|
|
|
- though only as long as the ChunkConfig is unchanged.
|
2014-07-27 05:24:34 +00:00
|
|
|
-}
|
2020-10-22 17:37:09 +00:00
|
|
|
chunkKeys :: UUID -> ChunkConfig -> Key -> Annex [ChunkKeys]
|
2020-10-22 16:57:58 +00:00
|
|
|
chunkKeys = chunkKeys' False
|
|
|
|
|
|
|
|
{- Same as chunkKeys, but excluding the unchunked key. -}
|
2020-10-22 17:37:09 +00:00
|
|
|
chunkKeysOnly :: UUID -> ChunkConfig -> Key -> Annex [ChunkKeys]
|
2020-10-22 16:57:58 +00:00
|
|
|
chunkKeysOnly = chunkKeys' True
|
|
|
|
|
2020-10-22 17:37:09 +00:00
|
|
|
chunkKeys' :: Bool -> UUID -> ChunkConfig -> Key -> Annex [ChunkKeys]
|
2020-10-22 16:57:58 +00:00
|
|
|
chunkKeys' onlychunks u chunkconfig k = do
|
|
|
|
recorded <- getCurrentChunks u k
|
2020-10-22 17:37:09 +00:00
|
|
|
let recordedl = map (ChunkKeys . toChunkList k) recorded
|
2020-10-22 16:57:58 +00:00
|
|
|
return $ addspeculative recorded $ if onlychunks
|
|
|
|
then recordedl
|
|
|
|
else if noChunks chunkconfig
|
2020-10-22 17:37:09 +00:00
|
|
|
then ChunkKeys [k] : recordedl
|
|
|
|
else recordedl ++ [ChunkKeys [k]]
|
2020-10-22 16:57:58 +00:00
|
|
|
where
|
|
|
|
addspeculative recorded l = case chunkconfig of
|
|
|
|
NoChunks -> l
|
|
|
|
UnpaddedChunks chunksz -> case fromKey keySize k of
|
|
|
|
Nothing -> l
|
|
|
|
Just keysz ->
|
|
|
|
let (d, m) = keysz `divMod` fromIntegral chunksz
|
|
|
|
chunkcount = d + if m == 0 then 0 else 1
|
|
|
|
v = (FixedSizeChunks chunksz, chunkcount)
|
|
|
|
in if v `elem` recorded
|
|
|
|
then l
|
2020-10-22 17:37:09 +00:00
|
|
|
else l ++ [SpeculativeChunkKeys v (toChunkList k v)]
|
2020-10-22 16:57:58 +00:00
|
|
|
LegacyChunks _ -> l
|
2014-07-27 05:24:34 +00:00
|
|
|
|
2014-07-28 17:19:08 +00:00
|
|
|
toChunkList :: Key -> (ChunkMethod, ChunkCount) -> [Key]
|
|
|
|
toChunkList k (FixedSizeChunks chunksize, chunkcount) =
|
|
|
|
takeChunkKeyStream chunkcount $ chunkKeyStream k chunksize
|
|
|
|
toChunkList _ (UnknownChunks _, _) = []
|
2020-10-22 17:37:09 +00:00
|
|
|
|
|
|
|
{- When chunkKeys provided a speculative chunk list, and that has been
|
|
|
|
- verified to be present, use this to log it in the chunk log. This way,
|
|
|
|
- a later change to the chunk size of the remote won't prevent accessing
|
|
|
|
- the chunks. -}
|
|
|
|
ensureChunksAreLogged :: UUID -> Key -> ChunkKeys -> Annex ()
|
|
|
|
ensureChunksAreLogged u k (SpeculativeChunkKeys (chunkmethod, chunkcount) _) =
|
|
|
|
chunksStored u k chunkmethod chunkcount
|
|
|
|
ensureChunksAreLogged _ _ (ChunkKeys _) = return ()
|