「scp resume」を調べようとすると

こういう非常に大事な小技も年に一回必要になればいいほう、となれば、なかなか身につける機会に恵まれないのな。

「「scp resume」を調べようとすると」に続くのは、「んなものはないので別のものを使わねばならん」である。

知ってる人は知ってる、んだと思う。「scp」そのものにレジュームやそれ相当の機能はない。ほんと不思議。こんくらいの当たり前のニーズなんか、ほとんど誕生時点から予測できたろうし、進化の過程で取り込むチャンスもあったろうに…。して私は「それを知らない人」だった、さっきまで。ゆえに、「年に一回必要になればいいほう」のたびに調べてはこずに「諦め続けてた」。つまり「失敗したので最初からやり直したらうまくいった」という「数時間から数日作業」を、「最大でも年に一回程度の頻度で」やり続けていた、ということ。

これの「ワタシなりの答え」は今回は書かない。そのうち書くかもしれんけれど、今はちょっと「おてすき」じゃないので、発想についてのメモにとどめとく。

どれも「scp そのものは諦める」アプローチとなるが、ネット民が真っ先に候補にあげるひとつはご想像通りの「rsync 使えばええやん」。正直 rsync が役に立つのは認めつつも、今私が直面しているのは「単体の大きなファイル一個の転送」なので、rsync がどうしても牛刀に思えちゃうのだよね。してもう一つが sftp を使うアプローチ。どちらの解もいつも通り stackoverflow で見つかる。して、その stackoverflow 解で一人だけ触れてる dd を使うアプローチが、実はワタシが思い付いたのと同じ発想なんだけれど、これがまぁメモしとかんと絶対思い出せないようなものでな。「skip」はいいよ、それはすぐに調べられる。問題はこれを ssh でやらねばならんということで。いわゆる「迷子になる」やつね。これについては stackexchange にわかりやすいのを見つけた。リモート側で標準出力に吐き出したのをローカル側にパイプして、というだけのことだけれど、こういうの、結構ソラでは出てこない。

「scp の resume がない」への解として「dd via ssh」を使う…というのは解としてはもちろん半分だよ。そもそも「何バイトまで取れてるか」を調べるのが必要だし、「その途中まで成功してるダウンロード」の中途ファイルと dd で新しくお取り寄せる断片には何の関係もないのだから、「その二つを結合するのがゴール」よ。標準的な unix コマンドだけでまかなうつもりなら前者は stat とかで、後者は cat だよ。

今日のワタシにはこれで存分に十分なメモになるのでこれでやめるけれど、これをスクリプトにするとかそういったおまとめはあると自分でも便利だと思うので、時間が出来たら書くかもしれない(し書かないかもしれない)。