46 lines
2.2 KiB
Text
46 lines
2.2 KiB
Text
|
[[!comment format=mdwn
|
||
|
|
username="joey"
|
||
|
|
subject="""comment 1"""
|
||
|
|
date="2018-10-29T17:51:27Z"
|
||
|
|
content="""
|
||
|
|
Looking at the code, it addurl clearly *does* use the urls returned by
|
||
|
|
CHECKURL. In Command/AddUrl.hs:
|
||
|
|
|
||
|
|
go deffile (Right (UrlMulti l))
|
||
|
|
| isNothing (fileOption (downloadOptions o)) =
|
||
|
|
forM_ l $ \(u', sz, f) -> do
|
||
|
|
let f' = adjustFile o (deffile </> fromSafeFilePath f)
|
||
|
|
void $ commandAction $
|
||
|
|
startRemote r o f' u' sz
|
||
|
|
|
||
|
|
`l` is the list of values it returns, and `u'` is individual urls from that list,
|
||
|
|
as opposed to `u` which is the url the user provided.
|
||
|
|
`u'` is passed to `startRemote`, and `u` is not.
|
||
|
|
|
||
|
|
Hmm, but in Remote/External.hs there is a special case:
|
||
|
|
|
||
|
|
-- Treat a single item multi response specially to
|
||
|
|
-- simplify the external remote implementation.
|
||
|
|
CHECKURL_MULTI ((_, sz, f):[]) ->
|
||
|
|
result $ UrlContents sz $ Just $ mkSafeFilePath f
|
||
|
|
CHECKURL_MULTI l -> result $ UrlMulti $ map mkmulti l
|
||
|
|
|
||
|
|
That does not have any kind of rationalle in [[!commit 8a17bcb0be91c345a52d78c08009285b0fcd6e3a]],
|
||
|
|
but the next commit added `doc/special_remotes/external/git-annex-remote-torrent`
|
||
|
|
and I think I can see why I felt it simplified things. That script always
|
||
|
|
replies with CHECKURL-MULTI, but a torrent often contains a single file, and
|
||
|
|
it would be perhaps bettter to use the original url provided to the user for such a
|
||
|
|
file from a torrent, rather than an url that asks for file "#1" from the torrent.
|
||
|
|
Although AFAICS either would work, and Remote/BitTorrent.hs contains just the kind
|
||
|
|
of special case for a single item torrent that I was wanting to avoid external
|
||
|
|
special remotes needing to worry about.
|
||
|
|
|
||
|
|
The other benefit to special casing UrlContents is that lets addurl --file specify
|
||
|
|
where to put the file, which the fileOption check in the first code block
|
||
|
|
above prevents for UrlMulti. But, that could just as well be handled by
|
||
|
|
adding a single file special case to the code in AddUrl.
|
||
|
|
|
||
|
|
I suppose changing this won't break anything, or if it does it was relying
|
||
|
|
on this undocumented behavior.
|
||
|
|
"""]]
|