a622488758
Removed undocumented special case in handling of a CHECKURL-MULTI response with only a single file listed. Rather than ignoring the url that was in the response, use it. This allows external special remotes that want to provide some better url to do so, although I don't entirely agree with using CHECKURL-MULTI to accomplish that. I'm more of the feeling that an undocumented special case that throws data away is just not a good idea. This could in theory break some external special remote program that relied on the current behavior, but its seems unlikely that it would because such a program must already handle the multiple url case, unless it only ever provides a single url response to CHECKURL-MULTI. Make addurl --file work with a single item CHECKURL-MULTI response. It already did for external special remotes due to the special case, but now it also will for builtin ones like the BitTorrent special remote. This commit was sponsored by Ilya Shlyakhter on Patron.
37 lines
2.4 KiB
Markdown
37 lines
2.4 KiB
Markdown
When an external special remote tells git-annex a fuller URL for a given file, git-annex-addurl does not use that information:
|
|
|
|
[2018-10-28 16:12:39.933464] git-annex-remote-dnanexus[1] <-- CLAIMURL dx://file-FJZjVx001pB2BQPVKY4zX8kk/
|
|
[2018-10-28 16:12:39.933515] git-annex-remote-dnanexus[1] --> CLAIMURL-SUCCESS
|
|
[2018-10-28 16:12:39.933568] git-annex-remote-dnanexus[1] <-- CHECKURL dx://file-FJZjVx001pB2BQPVKY4zX8kk/
|
|
[2018-10-28 16:12:40.469292] git-annex-remote-dnanexus[1] --> CHECKURL-MULTI dx://file-FJZjVx001pB2BQPVKY4zX8kk/A4.assembly1-trinity.fasta 11086 A4.assembly1-trinity.fasta
|
|
addurl dx://file-FJZjVx001pB2BQPVKY4zX8kk/ (from mydx) (to A4.assembly1_trinity.fasta) [2018-10-28 16:12:40.469503] read: git ["--version"]
|
|
|
|
It would be better if, in the above log, the URL key was based on dx://file-FJZjVx001pB2BQPVKY4zX8kk/A4.assembly1-trinity.fasta , which would preserve the .fasta extension in the key and therefore in the symlink target.
|
|
|
|
> [fixed|done]] --[[Joey]]
|
|
|
|
Also, it would be good if the external special remote could return an etag
|
|
for the URL, which would be a value guaranteed to change if the URL's
|
|
contents changes; and if git-annex would then compute the URL key based on
|
|
the combination of URL and etag.
|
|
|
|
> This might be a good idea if sufficiently elaborated on, but I am a one
|
|
> idea, one bug, one page kind of guy. I dislike reading over a long detailed
|
|
> discussion of something, like the problem above and my analysis of it,
|
|
> only to find a second, unrelated discussion of something else.
|
|
> Suddenly the mental state is polluted with
|
|
> different distinct things, some fixed, other still open. The bug tracking
|
|
> system has then failed because it's not tracking state in any useful way.
|
|
> Which is why I've closed this todo item with my fix of
|
|
> a single item from it. --[[Joey]]
|
|
|
|
It'd also be good if there was a option to automatically migrate URL keys
|
|
to the default backend whenever a file from a URL key is downloaded. Also,
|
|
to record the checksummed key (e.g. MD5E) as metadata of the URL key (in a
|
|
field named e.g. alternateKeys), and if addurl --fast is later done on a
|
|
URL key for which a checksummed key is recorded in the metadata, to add the
|
|
checksummed key instead of the URL key .
|
|
|
|
> Again, mixing discussion of several things in one place is a good way to
|
|
> muddy the waters. I think this idea has several problems, but don't want
|
|
> to discuss them here. --[[Joey]]
|