]> dgit.raspbian.org Git - git-annex.git/commit
export: Added --from option
authorJoey Hess <joeyh@joeyh.name>
Thu, 8 Aug 2024 16:04:39 +0000 (12:04 -0400)
committerJoey Hess <joeyh@joeyh.name>
Thu, 8 Aug 2024 16:08:55 +0000 (12:08 -0400)
commit7294d23d78cca5cde63ac8b79857fffcf56e2031
tree26d53929253e577be2a6058538a049c448438b7e
parentbd677bb65a4e93a867e4aa8ace108f358200f7fb
export: Added --from option

This is similar to git-annex copy --from --to, in that it downloads a
local copy, locks it for removal, uploads it, and drops it. Removal of
the temporary local copy is done without verifying numcopies for the
same reason as that command.

I do wonder, looking at this, if there's a race where the local copy
gets used as a copy to allow some other drop in the narrow window after
it is downloaded and before it gets locked for removal. That would need
some other repository to have an out of date location log that says the
repository contains a copy of the key, in order for it to try to use it
as a copy. If there is such a race, git-annex copy/move would also be
vulnerable to it. It would be better to lock it for removal before
starting to download it! That is possible in v10 repositories, which do
use a separate content lock file.

Note that, when the exported tree contains several files that use the
same key, it will be downloaded repeatedly, once per time needed to
upload it. It would be possible to avoid that extra work, but it would
complicate this since the local copy would need to be preserved, locked
for removal, until the end. Also, that would mean that interrupting the
export would leave possibly a lot of temporarily downloaded keys in the
local repository, while currently it can only leave one.
CHANGELOG
Command/Export.hs
Command/PostReceive.hs
Command/Sync.hs
doc/git-annex-export.mdwn
doc/todo/git-annex_proxies.mdwn