cafegale(LeafCage備忘録)

LeafCage備忘録（はてなダイアリー）と統一しました。

MEGAsyncが逆同期をしてくるのでBox にクラウドストレージを移行しようかとしたけど辞めた理由

以前のMEGAsync の評価の記事→Dropboxの移行先としてのMEGAsyncの評価 - cafegale(LeafCage備忘録)

削除したファイルを勝手に復活させる逆同期をMEGAsync がやらかしてきて、古いファイルが復活したせいでコンパイルが通っていたのが通らなくなったという事件が起きて、（git statusで古いファイルが存在するのが見えてわかった）、いよいよこのような整合性が大切なファイルをMEGAsyncに任せておけないと思ったので、Boxに乗り換えようとした。

結論から言うとBoxは乗り換えるのに不安要素があった。

  • 無視されるファイルが決まっていて変更できない。tmpが名前に含まれてるファイルや隠しファイルが同期されないのは致命的。
    support.box.com
  • ファイルシステム上にファイルがあるように見えるが、実体はクラウドにある形式。フォルダ右クリックで出るコンテキストメニュー内の「オフライン利用可」を選択するとそのマシンではオフラインで利用できるが、代わりに他のマシンではクラウドでの利用を余儀なくされそう（おそらく排他的）
    この認識は間違ってる可能性がある。まだ検証中。
  • クラウドストレージディレクトリ「Box」の場所はレジストリを触らないと変更できない。

support.box.com

  • Ctrl Shift Alt B というキーをグローバルに奪い取ってしまう。
  • クライアントソフトに設定項目がない。ヘルプやログアウトはあるけど見事に設定についての項目は何も用意されていない。


まだ検証が必要だがその間はMEGAsyncにファイル管理を任せることになり、しばらく心臓に悪そうだ。
ところで、MEGAsyncによる同期事故の報告についてオンライン上で見かけないのが不思議だ。私の環境が悪いのか？

TVからのTSファイルをffmpegでmp4エンコードする現在の設定

ことわっておくが私もこのffmpegのオプションの詳細についてよく把握できていないものが多い。それほど複雑ってことだ。
理屈がわからないまま値を変更していって試行錯誤で決まったものも多く、

readonly SVGA="800:600"

ffmpeg -y -dual_mono_mode main -i "src.ts" -movflags +faststart \
  -flags +loop -partitions parti4x4+partp8x8 -me_method umh -subq 8 -me_range 16 -g 250 -sc_threshold 40 -i_qfactor 0.71 -b_strategy 1 -qmin 10 -rc_eq "blurCplx^(1-qComp)" -bf 16 -bidir_refine 1 -refs 16 -deblock 0:0 \
  -c:v h264_qsv -b:v 4M -crf 25 -pix_fmt yuv420p -profile:v main -look_ahead 0 -vf yadif,scale=$SVGA -preset slow \
  -c:a libfdk_aac -vbr 4 "out.mp4"
  • -dual_mono_mode main
  • -c:v h264_qsv -b:v 4M -crf 25
  • -c:a libfdk_aac -vbr 4
    • FDK-AACライブラリを使って、可変長(VBR)の5段階中4の品質でエンコードする。（だいたいビットレートが105～110kbpsくらいになる。）
    • -c:a copy の無劣化でやるのが一番楽なのだが、-c:a copyだとエラーが出てエンコードできないケースがあるので、多少の劣化に目をつぶって汎用性を持たせた結果。
    • VBRなハズなのにMediaInfoではCBRと表示されるから混乱した。音声だけ抜き出すとVBRと表示されるのでますます混乱する。深く考えないことにした（このことについてくどくど後述している）。
  • -flags +loop -partitions parti4x4+partp8x8 -me_method umh -subq 8 -me_range 16 -g 250 -sc_threshold 40 -i_qfactor 0.71 -b_strategy 1 -qmin 10 -rc_eq "blurCplx^(1-qComp)" -bf 16 -bidir_refine 1 -refs 16 -deblock 0:0

AACについてのさらなる探求

音質比較記事
ch.nicovideo.jp
kamedo2.hatenablog.jp
AACエンコーダの音質比較

VBRにするか、HE-AACか

AACとは (エーエーシーとは) [単語記事] - ニコニコ大百科
ニコニコ大百科を見る限りAACのビットレートをすごく小さくしない限りは、HE-AACにする意味はあまりなさそうだ。

-vbrフラグを付けてるのに、MediaInfoでmp4のデータを見るとオーディオがCBRと表示されるため、「もしかしてQSVだと強制的にCBRにされる？」と疑ったが、そのデータからAACだけを抜き出すとVBRと表示されるため、よくわからんがMediaInfoの解析ミスということにしておく。
PotPlayerのようなCtrl+F1で再生中のリアルタイムビットレート確認できるプレイヤーでも刻刻ビットレートが変動しているのが見えるし、実質VBRなのだろう。

ここで LC-AAC、HC-AACの違いは

LC-AAC：AAC-LC (AAC Low Complexity)と呼ばれる基本機能だけのもの
HE-AAC ：High-Efficiency AAC、aacPlus、AAC+SBR、aacPlus Version 2、Enhanced aacPlus、AAC+SBR+PS と呼ばれる低ビットレートで高音質となるもの

となっています。

HE-AAC を使う場合は

  • profile:a aac_he

または

  • profile:a aac_he_v2

を指定します。
v2のほうが新しい規格で、48kbps 以下の低ビットレートでの音質が改善します。

  • vbr オプションの [品質] の部分には 1〜5 を指定します。

HE-AAC を使う場合は 3 が最高品質、
そうでない場合は 5が最高品質です。

FFmpeg で高音質 AAC 変換できるようにする
  • profile:a で指定できるのが

aac_low :AAC-LC 何も指定しないとこれになる
aac_he :HE-AAC 44.1kHzでは28kから使える 推奨32k-48k
aac_he_v2 :HE-AACv2 44.1kHzでは28k-64kまで使える 推奨16-24k

【ffmpeg】 fdk-aac を ffmpeg に組み込む - ニコニコ動画研究所

なるべく小さい音声ファイルを作る - Qiita

サンプルレート-arについて

映像の場合は48kHzが標準（音楽業界では44,1kHz）参考。特に指定しない限りはエンコード時にエンコード元のサンプルレートが引き継がれる。

Windows用のlibfdk_aacが使えるffmpegを手に入れるまでの長い道のり

以前からAACエンコーディングするならFDK-AACという情報は得ていた。
ffmpegのオーディオコーデックの指定：tech.ckme.co.jp
ただ、ライセンスの問題から、FDK-AACを組み込んだffmpegは配布されておらず、使いたければ、自分でビルドするしかないらしく、かつて一度ビルドしようとして失敗して、あきらめてAACエンコーディングを行わない方針をとっていた。
TVのTSファイルをmp4にエンコードするのに、-c:a copyで音声部分はエンコードしないで無劣化音声をそのまま使うようにしていた。ただ、それだとエラーが出てmp4エンコードできないファイルを発見したので、再びFDK-AAC付きのビルドに挑戦することにした。
（以下のようなメッセージが出てエンコードが開始しない。）

Last message repeated 6 times
[mp4 @ 000001af4198b2c0] Error applying bitstream filters to an output packet for stream #1: Not yet implemented in FFmpeg, patches welcome
av_interleaved_write_frame(): Not yet implemented in FFmpeg, patches welcome
[mp4 @ 000001af4198b2c0] Error applying bitstream filters to an output packet for stream #1: Not yet implemented in FFmpeg, patches welcome
av_interleaved_write_frame(): Not yet implemented in FFmpeg, patches welcome
[mp4 @ 000001af4198b2c0] Error applying bitstream filters to an output packet for stream #1: Not yet implemented in FFmpeg, patches welcome
av_interleaved_write_frame(): Not yet implemented in FFmpeg, patches welcome
[mp4 @ 000001af4198b2c0] Error applying bitstream filters to an output packet for stream #1: Not yet implemented in FFmpeg, patches welcome
av_interleaved_write_frame(): Not yet implemented in FFmpeg, patches welcome
[mp4 @ 000001af4198b2c0] Error applying bitstream filters to an output packet for stream #1: Not yet implemented in FFmpeg, patches welcome
av_interleaved_write_frame(): Not yet implemented in FFmpeg, patches welcome
[mp4 @ 000001af4198b2c0] Error applying bitstream filters to an output packet for stream #1: Not yet implemented in FFmpeg, patches welcome
av_interleaved_write_frame(): Not yet implemented in FFmpeg, patches welcome
[mp4 @ 000001af4198b2c0] Error applying bitstream filters to an output packet for stream #1: Not yet implemented in FFmpeg, patches welcome
av_interleaved_write_frame(): Not yet implemented in FFmpeg, patches welcome
[mp4 @ 000001af4198b2c0] Error applying bitstream filters to an output packet for stream #1: Not yet implemented in FFmpeg, patches welcome
av_interleaved_write_frame(): Not yet implemented in FFmpeg, patches welcome

先に結論

ffmpeg-windows-build-helpersを使う

Windows Subsystem for Linux (WSL) 上でWindows用のffmpegをビルドしてくれるスクリプト。
github.com
Windows用FFmpegをWindows 10でビルドする (Bash on Ubuntu on Windows)
ffmpeg-windows-build-helpersの使い方 | EncTools
ffmpeg-windows-build-helpersでWindows版ffmpegをビルドする | つくみ島だより←最も参考にした。

MSYS2/MinGwを使ってビルドしようと苦戦するより、クロスコンパイル（linuxからwindows用プログラムをコンパイルする）できるならそうした方が謎のエラーに格闘して無駄な時間を過ごさなくていいと学んだ。

実行したコマンド

$ ./cross_compile_ffmpeg.sh --build-ffmpeg-static=y --build-intel-qsv=y --disable-nonfree=n

dllを使わず単体にしたいから--build-ffmpeg-static=y、fdk-aacを使いたいから--disable-nonfree=n。
そうしたらいろいろ不足しているパッケージを要求される。
大抵のパッケージはlinuxbrewからでもインストールできるが、 clangとpaxはlinuxbrewでは提供されていないので、それだけはaptで入れなければいけない。

$ sudo apt install clang pax

あと、パッケージが揃っていてもなんか実行前にエラーが出るときは

$ sudo bash -c 'echo 0 > /proc/sys/fs/binfmt_misc/WSLInterop'

を実行する（この状態は再起動すると元に戻る。）。

あと、linuxbrewでインストールする際に、pyenvのバージョンが上がったせいで、pythonが呼び出せなくなって一度スクリプトが異常停止した。
pyenvがバージョンアップしたときには

pyenv rehash

を実行して環境を更新しなければいけない。*1
参考：pyenvをアップデートしたらlibexec/pyenv: No such file or directoryとか言われた話 | エンジニアもどきの技術メモ

3時間くらい？して、ビルドが完了し、

ffmpeg-windows-build-helpers\sandbox\win64\ffmpeg_git_with_fdk_aac

以下にffmpeg.exe などのファイルができているので、それをWindowsのパスの通ったディレクトリに移して終了。

杜撰ブログ : WSLのUbuntuでWindows用ffmpegをビルドするPart2←でもうまくいかない例もあるようだ。


失敗したルート

msys2のmingwで自前でビルドする

参考情報
fdk-aacとx264が使えるffmpegをビルドする(Windows)←もっとも参考にした
ffmpegをwindows向けにビルドした方法 - Qiita←msys2の他にVisual Studioでの方法も載ってる
Windows10 でffmpegをコンパイル：ろくさぶろ：So-netブログ

いくらやっても最終的に

$ ./configure --prefix=/mingw64/x86_64-w64-mingw32 --enable-gpl --enable-version3 --enable-nonfree --enable-libfdk-aac --enable-libx264 --extra-ldflags=-static --optflags=-O2
ERROR: libfdk_aac not found

というエラーで停止してしまう。

$ pacman -S mingw-w64-x86_64-fdk-aac

していても、

・fdk-aac のコンパイル
cd fdk-aac
./configure --prefix=/mingw64/x86_64-w64-mingw32
make -j3
make install

していてもだ。なぜかfdk-aacライブラリを認識してくれない。

media-autobuild_suite

github.com
QSV 対応の ffmpeg をつくる | ニコラボ←ここでお勧めされていて知った。

灰色のプロンプト画面からの結構長いダイアログに答えていくと最終的に自動ビルドしてくれるスクリプト。
途中でビルドが失敗する。

Likely error (tail of the failed operation logfile):
libtoolize: linking file 'm4/ltversion.m4'
libtoolize: linking file 'm4/lt~obsolete.m4'
configure.ac:41: error: installing './ar-lib'; error while making link: Operation not permitted
configure.ac:39: error: installing './compile'; error while making link: Operation not permitted
configure.ac:42: error: installing './config.guess'; error while making link: Operation not permitted
configure.ac:42: error: installing './config.sub'; error while making link: Operation not permitted
configure.ac:26: error: installing './install-sh'; error while making link: Operation not permitted
configure.ac:26: error: installing './missing'; error while making link: Operation not permitted
examples/c/decode/file/Makefile.am: error: installing './depcomp'; error while making link: Operation not permitted
autoreconf: automake failed with exit status: 1
autogen failed. Check D:/media-autobuild_suite/build/flac-git/ab-suite.autogen.log
This is required for other packages, so this script will exit.
  Creating diagnostics file...

All relevant logs have been anonymously uploaded to https://0x0.st/iDAb.zip
Copy and paste [logs.zip](https://0x0.st/iDAb.zip) in the GitHub issue.
Make sure the suite is up-to-date before reporting an issue. It might've been fixed already.
Try running the build again at a later time.

こんなエラーが出る。"Operation not permitted" と出ることから何かしらの権限的なエラーだとは思うのだが。

試していないルート

ＦＦＭＰＥＧビルド改自動化シェルスクリプトX0008

ffmpegビルド(AAC+.FDK-AAC)・がぁんさん自動ビルド編:moribitoブロマガ - ブロマガ
ツールテスト-ニコニコミュニティ
古そうなので試していない。

【AAC+】 HE-AAC が使える ffmpeg をつくる方法 - ニコニコ動画研究所←ほかにもビルド自動化スクリプトはあるったようだ。これは2012年の話なので現在ではほとんどのスクリプトは削除されたか更新終了したかしたようだ。

*1:こういうことがあるから私はpythonをグルー言語として使うことには否定的だ。python本体やpyenvがバージョンアップするとパスが変わって動かなくなるということが以前にもあって、気づかないうちに動かなくなってるの怖って思った。

Dropboxの移行先としてのMEGAsyncの評価

mega.nz
フリーアカウントの容量は50GB。3ヵ月ログインなしでアカウント削除*1（実際は8ヵ月くらいまでは待ってくれるらしい。消される一週間前にログインしないと消しますよメールは来る）。

ダメなところ
  • iPhone上のアプリからはファイル編集ができない。閲覧のみ。
  • 起動したのにずっとファイル同期が完了しないことがある。特にスリープから復帰したときにこの現象が発生しやすい。どこか一つのファイルの同期でつまずくとずっとそのファイルの同期をリトライして同期が進まない。
    • クライアント再起動で治ることもあるが、治らない場合、マシン再起動か、または手動でファイルコピーをしないといけない。つらみ。
  • マシン間で最新ファイルの競合が発生したときの挙動が意味不明。
    • DropBoxなら ({ホスト名} の競合コピー {日付})とリネームされたファイルが同期されるからdiffで手動で統合ができる。MEGAsyncは競合が発生していることがローカルでは全然わからない。オンラインストレージ上ではなんと同じフォルダ、同じファイルが2つできていたりする。
    • ファイルやフォルダを移動させたとき、移動元にも移動先にもファイルを作成するというひどい競合解消法を取ってくる。MEGAの管理下にあるファイルシステム全体が信用のおけないものになる。
  • どのファイルを同期しているのかDropboxに比べてわかりづらい。
いいところ
  • 同期するフォルダ名を自由に決められる。「MEGAsync」以外のフォルダでもいい。
    • 保存される場所が決まっていて変更できないような設定ファイルも同期対象にすることができる
  • 同期するフォルダを何個でも指定できる。
  • 除外したいファイルパターンを指定できる。
  • 同期するマシンの数に制限はない（Dropboxはフリープランは3台までに制限されてしまった(2020年9月現在)）
  • ほとんどのOSに対応している？
結論

同期が不安定。競合発生時の挙動が意味不明で不安になるのでその点は頑張ってほしい。
もうちょっとこの不安定さを改善してもらわないと、他の手段を探すことになりそう。
Dropboxの台数制限のために乗り換えざるを得なかったが、あらためてDropboxの同期アルゴリズムが優れていたことを実感した。

*1:Dropboxも90日アクセスなしでデータ削除なのでこの点は同じ？

windows使ってるとHOMEの場所が分散したりパスの問題で悩まされる（愚痴

実に疲れる。
windowsのパスの解釈がおかしかったり、環境変数HOMEを無視するソフトの存在が。*1

環境変数HOMEを設定していようと、ある特定のソフトは関係なくwindowsのユーザプロファイルディレクトリ（C:\Users\{ユーザー名}\）の方を見に行くし、
MSYS2のopenssh は MSYS2の /home/{ユーザー名} の方を見に行く。（go言語やhaskellで作られたソフトとかがそんなことをしてくる）

ここにきて、ghq が、Git bash から起動したときには正常に、ghq.rootに~が含まれているとき環境変数HOMEに解釈してくれるが、MSYS2のシェルからだと~の解釈がおかしいことに気づいた；
環境変数HOMEに D:\home\ を設定していたら、D:\home\ghq ではなく、D:\d\home\ghq をghqルートディレクトリに設定してくる*2。

こんなに苦悶を味わうのなら、いっそのこと環境変数HOMEを設定するのはやめてデフォルトのwindowsユーザプロファイルディレクトリを使ってる方が幸せになれる気がしてきた。
ただ、環境変数HOMEを設定していないとおかしなところにファイルを作られる気がするのと、精神衛生によくないんだが
またはもうwslだけを使うのがいいのだろうが、windowsローカルで動かす方が気持ちがいいからそういうわけにはいかないんだよなぁ。

windowsの中だけで過ごしているうちは幸せで、だが*nix系のツールや作法に足を踏み出すと急激にSUN値が上がっていく。

そう言えばそもそもnvm-windowsをMSYS2で実行できないから仕方なくghqでnodistを取ってこようとしたことから始まったyak shavingだった。

なぜか MSYS2上で nvm use {バージョン番号} しても、nodejsのnpmのPATHが通されないことから始まって、調べてみると NVM_HOME とか NVM_SYMLINK が自動で設定されなくて、仕方なく手動で設定したのに相変わらず nodeに PATH通してくれなくて、こうなったらと直接PATHに nodeのパスを加えてもなぜか削除されて、しょうがないから nvm-windows を使うのをあきらめてnodistを使うようにしたという、もう本当に文字にするとしょーもないことで何時間も使って、挙句にこのPATH問題だぜ？
MSYS2が原因の問題が起きたのは今に始まったことじゃないが、こんなにいろいろ起こるとMSYS2を使うのをやめた方が幸せになれるんじゃないかという気すらしてくる。

↑nvm-windows がうまく動かないときには環境変数NVM_HOMEとNVM_SYMLINKを手動で設定したうえでこの2つをPATHに加えたらいいんだって

参考：nvm-windows 導入 - Qiita
わかるかこんなの！

全般的にWindowsに疲れた

パスの問題、文字コードの問題、もっとずっと昔に解決されているべき問題だったのだ。

*1:Windowsには文字化けエンコード問題もあって折につけ私を悩ませてきた

*2:ghqについて、windowsはghq.rootを設定せず、%USERPROFILE%/ghq というデフォルト設定で運用するとMSYS2でもほかのシェルでも同じように使えて一番スマートだろう。ghqに限らず、パスをデフォルト設定から変更するとおかしくなるソフトはもうあきらめてデフォで使うしかない

windowsでMSYS2とWSLとネイティブインストールの使い分け

notation

windows上での開発環境について、かつてはmsys2とそれに付随しているmingwですべてを賄おうとしていたが、msys2/mingwでnodejsがサポート外になったことと、ネイティブでしかサポートしていないアプリや開発環境が増えたこと、そもそもネイティブのPATHにmsys2やmingwのPATHを通すのは間違いのような気がしてきたので、これからの使い分けについて考えてみる。
あと不用意にパソコンを初期化してしまってローカルにあった設定とかわからなくなったし。

追記：nodejs(npm)の補完がmsys2のzshで動いてくれない（というかMingw の bashでしか動いてくれない）ので、zshの上でnpm使う計画は頓挫した。
completion: refused to run under CYGWIN bash · Issue #13624 · npm/npm
yarn なら大丈夫のようだ。

Windowsネイティブ

安定していて互換性あることは保証されるが代償としてレジストリやPATHが汚されていく。

  • PATHを通さなければいけない欠点はscoopに任せるのでおおよそ解消される。
    • 単体のアプリなら、scoop\shimsに追加されていくからPATHが無尽蔵に増えていくことはなさそうだが、それでもときにscoopが勝手にPATHを追加していくことはある。例えばnodejsを入れたらscoop\apps\nodejs\currentとscoop\apps\nodejs\current\binを追加された。
  • レジストリを汚す可能性がある。scoopに任せてもレジストリは汚れていくんだろうか？
  • GUIを開発するならネイティブにインストールするしかない？
  • scoopでは使用可能なものが少なく、windowsネイティブでも使用できないツールがある（rbenvなど）。
MSYS2

ネイティブで使えないUnix系のツール（zshとかtmuxとか）を使うときに頼りにする。

  • コマンドプロンプト等から呼ぶときにはPATHを通す必要がある。
  • windows側のPATHを汚したくないなら同梱されているランチャ(msys2.exe, mingw32.exe, mingw64.exe)から起動するのが基本になる。
  • なぜか内部にmsys2とmingwのエリアが分かれてあって、本格的に開発言語をインストールするときにはmingw側にインストールしないと不具合が出る（msys側は言語バージョンが低かったりするんだっけ？それともサポートされてる言語が少なかったんだっけ？忘れたけど）
    • mingw側を使いたい場合はmsys2.exeではなくmingw32.exe, mingw64.exeから起動しなければいけない（そうしないとmingw側のPATHが通らない）。
  • mingw側にインストールした言語からwindowsのGUIを開発することができた。100%互換性があるかどうかは不明。
  • nodejsがサポートされなくなった（削除された）
  • pacman の構文が気に入らない。
WSL
  • windows側のPATHを通す必要がない（コマンドプロンプト等からでもwsl rubyでrubyを呼べる）→PATHが汚くわけわからなくなるのを防げる
  • （おそらく）GUIを扱えないと思う。

欲求

  • なるべくネイティブのPATHやレジストリを汚すような真似はしたくない。
  • ネイティブのPATHにmsys2のPATHを通すのをやめたい。ネイティブのPATHは勝手に足されて自分で設定したものがわからなくなってくるし、意図せずunix系統のコマンドが呼ばれるのはよくないのではないか。

以上を踏まえての方針

  • msys2のシェルをメインに使う。MSYS2_PATH_TYPEをinheritにしてwindowsの環境変数を受け継ぎ、主にscoopで入れたネイティブプログラムも実行できるようにする。
  • msys2はmingwを使わずmsys2側だけ使い、役割はツールの提供だけの最低構成にする。
  • 実行環境の提供はWSLに任せ、wslコマンドで呼び出すようにする。
  • wslで動かない状況が発生したとき、scoopでインストールし、ネイティブで実行する。
  • *nix環境で動かすときにはwsl付き、ネイティブで動かすときにはwslなしと、動作環境を明瞭にする。

これまでmsys2のmingwに実行環境を作っていたのをWSLに役割を移す。msys2内のmingwの立ち位置が中途半端だったし、プログラムがmsys側にあるのかmingw側にあるのか気にしたくなかった。

調べたところMSYS2も、自己完結して動くアプリ（エディタやファイラなど）はmsys2側で提供し、実際のプログラミング言語の提供はmingw側に任せmsys2は関知しない方針を貫いているようで、つまりはmingwの代わりにWSLを使っても何の問題もない。
MSYS2にはこういう未来が見えていたのだろうか。

Consider

C言語関係のコンパイル環境は MinGW32/64 を使うか、さもなくば MSVC(Microsoft Visual C++)を使う必要がある（そしてどうもMSVCはVS command prompt から実行しないと動かないそうだ）。こういうことを鑑みると、Windows上で動くC言語系をコンパイルする環境のみ、MinGW32/64 で構築しておくのも一案だ。とはいえWSLのパスにWindowsの$PATHを加える方針でやっていると思わぬ競合が生じそうで怖い（WSLローカルの環境がPATHの前の方に来るとは言え）。まぁ少なくとも、Windowsネイティブで（例えばscoopなどで）makeが提供されるようなことは今後しばらくも起こらないだろうということで、C環境については割り切ってMinGWを使うのもいい。
今のところとりあえず別にmsys2環境を分けて、そちらだけにMinGWの環境を立てているが。

ちなみに msys2/mingw にC環境を構築するコマンドは以下

$ pacman -S base-devel mingw-w64-i686-toolchain mingw-w64-x86_64-toolchain

MSYS2 による gcc 開発環境の構築 ― gcc パッケージ群の導入 | text.Baldanders.info
パッケージグループなので、実際は結構な量のパッケージがインストールされる（pacman -Sg ＜パッケージグループ名＞ でどんなパッケージが含まれているか確認できる）。

windows更新したらNAS（LANDISK-HDL2-A）にアクセスできなくなった。

ネットワークのコンピューター一覧にNASのフォルダが表示されなりアクセスできなくなった。

以下のサイトを参考にSMB 1.0/CIFS共有のサポートを有効にすることで解決した。
itojisan.xyz

注意: ただし、SMB 1.0/CIFS共有のサポート機能は、脆弱性が見つかりWindows 10 ver1803 のアップデートで、無効となったプロトコルです。非推奨のプロトコルになるので、有効にする場合はセキュリティ面でリスクがあることを理解の上、有効化してください。

なお、今現在、私にとってもっと深刻なことが起きた。Windows 10を「回復ドライブ」で回復させたら消してはいけないパーティションも削除され、少なくとも一か月半のデータを喪失した。パーティション切ってるシステムドライブだけリセットされるだろうと高を括っていたらまさかの結果だった。アドレナリンが出て臨戦態勢になってるのがわかる。