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]]
|