【Bash】Windows Subsystem for Linux【WSL】4

Install the Windows Subsystem for Linux
https://docs.microsoft.com/en-us/windows/wsl/install-win10

前スレ
【Bash】Windows Subsystem for Linux【Ubuntu】3
http://mao.2ch.net/test/read.cgi/linux/1528141781/

>>680
> オフライン中に別環境からパーティションを半端に弄られたり、あるいは動作中に介入されるような不味い事にはならない。

オフライン中に別環境からパーティションを半端に弄られると
Linuxは壊れるんか？

つまり別ディスクから起動して書き換えるってことに相当するんだが
それでファイルシステムが壊れることはないだろ

だいたいWSLでは「パーティションをいじる」ことはできない。
パーティションを管理してるのはOS（Windows）なんだから

すこしWSLのファイル管理を勉強したほうが良いよ。
LinuxじゃないんだからWSLがデバイスを直接管理したりしてないの

>>682
> 毎回、WSLはOSじゃないけどWSL上で動作するLinuxプログラムの実行環境が〜

Linuxプログラムの実行環境なんてのも存在しない。仮想マシンじゃあるまいし。
単にLinuxのシステムコールをWindowsのカーネルAPIに置き換えてるだけ

カーネルから見れば、LinuxアプリもWindowsアプリも同じ環境で動作しているように見える。

連投粘着ウザいよ
そんなに言いたいならTripでもつけてやってよ
別に論破する必要ないから、本屋でも行って1000年ROMってろ（ﾊﾅﾎｼﾞｰでいいし

>>686
ハイ論破。

WindowsからLinuxファイルへのアクセスが可能に 〜「Windows 10 19H1」におけるWSLの改善
https://forest.watch.impress.co.jp/docs/news/1170221.html
WindowsからLinuxのファイルにアクセスする仕組み（Windows 10 version 1903）
https://kledgeb.blogspot.com/2019/02/wsl-167-windowslinuxwindows-10-version.html

>>684
>オフライン中に別環境からパーティションを半端に弄られると
>Linuxは壊れるんか？

オンライン中に別システムからちょっかい出されたら壊れるだろそりゃ
壊れないケースもあるだろうけどさ

編集でなくてrobocopyとかxcopyで
%userprofile% を別のディスクにバックアップしても壊れるんやろか？

WSL では、Windows 側のsjis のファイル名が、

Linux 側で見ると、自動的に、UTF-8 に変換されるのが、すごい！

もともとNTFSはUTF-16で、api使うときにシステムロケールに変換してるから、その延長でしょう。

>>689
> オンライン中に別システムからちょっかい出されたら壊れるだろそりゃ

だから別システムってなんだよ？
WSLのアプリはNTカーネル上の1プロセス。
単なる別プロセスでしかないんだが。

えとさぁ、WSL用の別のOSがいて、そっちがWindowsの制御外から
デバイスごと管理してるわけじゃないんだぞ？わかってんのか？

>>691
Windowsはファイル名をUTF-16で管理してるのだから
UTF-8と相互変換するのは簡単

改行と引用ウザイ
引用マウントしたいならふたばでも行ってくれ
其れかいっそブログでも書いてここに貼っとけばエエやん。論争大好きマンなの？

はい。論争大好きここでマウント取りたいマンですよ？

うわっキモ・・・

ごめん、マジひくわー

しかし考えてみたら凄いことだよな。
Windowsで普通にLinuxソフトが動くもんな。

ExplorerでShell芸が輝くわぁ…
ネイティブでウィンドウシステムサポートしたら、ユーティリティ系でもなければデスクトップ環境系のLinuxの需要下がるよな
まあそれでもxubuntuとかお古PCに入れるんだろうけど。

>>693
別システムは別システムだよ
なんでWindows配下のプロセスの話になるんだよ

>>701
やっぱりWSLが別システムだって思ってんのか？
同じシステム上で動いていて、単に使ってるAPIが違うだけだぞ

その証拠にタスクマネージャーで見ると、WSLで動いているプロセスが
Windowsプロセスと同じように見える

ファイルはWindows（というかNTカーネル）が管理していて
どちらからロックを掛けても、同じようにロックが掛かる
WSLにドライバは存在せず、Windowsと同じドライバが管理してる
ファイルシステムだってそう。WindowsだろうがWSLだろうが
共通のドライバによって管理されてる。
だからどちらからどのタイミングで使ってもファイルシステムが壊れることはない

Windowsから触って壊れるのはファイルシステムではなくWSL上のメタデータが保存されないってだけ
ファイルシステムからみれば壊れているわけじゃない

WSLとか関係なくない
DBとかでもデータファイル直でいじらんだろ

>>702
なんでWSLの話だと思い込んでるのかなあ。

>>704
今までの話の流れとスレタイを見ろ

>>703
それは全く別の話。

WSL起動中でないと書き込みができないから安全とか
意味不明なことを言ってるやつがいる。
（WSLが別システムだから？意味不明ｗ）

こっちは書き込みの安全性についてWSL起動中かどうかは関係ないといってる。
直接弄った時の安全性は、WSLの起動とは関係ないだろ？

WSL起動中でないと書き込みができないのは
ファイルが壊れるとか別システム（笑）とかじゃなくて、
ストアアプリでファイルはそのアプリ用に隔離されてるから
直接ファイルを弄ることはセキュリティポリシーに反するからだろう
ファイル自体は同じOSが管理してるんだから壊れることはない

>>680の何が間違ってるのか理解できてないようだから書いておくと

> Windows側からの操作は動作中のWSL(Linux)環境経由で読み書きするので、・・・(1)
> Linux上で「Linuxでも別プロセスが勝手に書き換えることはある」のと同じ扱いとなり、・・・(2)

この(1)が全く関係ない。

(2)のLinux上で「Linuxでも別プロセスが勝手に書き換えることはある」のと同じ扱い
になるのは、WSL（Linuxではない）環境経由だろうが、WSL環境以外だろうが同じ。
WSL環境以外から書き込んでも、(2)と同じ扱いになる。
だから(1)は全く関係ない。

WSL側はWindows側の挙動を知りようがないから、appdata以下を直で弄られてもWSL上のLinux環境からは察知できず、メタ情報にも齟齬が発生する。
NTFS上のファイルとしては無事でも、WSL上のLinux環境からは破綻してしまっていたのがこれまで。
19H1ではWindows側にブリッジを作り、\\wsl$〜というUNCパスを使えば書き込み処理が起動中のWSL経由で行われ、WSL上のLinux環境からも関知される。
「実際の読み書きは土台のWindowsがやっているのだからファイルやメタ情報が壊れる訳がない」と繰り返しているアホは、この構造を理解できていない。
構造を理解できていないために、支障なくアクセスするためにはWSL環境が起動していなければならない理由もできていない訳だ。
無知で無能なくせに、やたらと攻撃的でマウント気質。まあ控え目に言ってクズ野郎ですな。
こちらとしても手加減する理由がないので、思う存分叩き伏せられる。

環境とかシステムって単語使うとまた噛みつかれるで
厳密君の言葉尻チェックうるさすぎ

>>709
なんでいちいち関係ない話を付け加えるんだ？

> WSL側はWindows側の挙動を知りようがないから、appdata以下を直で弄られてもWSL上のLinux環境からは察知できず
さも検知できれば大丈夫みたいな言い方をしてるけど、検知の有無は関係ない
そもそも（ファイル更新検知のためのAPIを使わない限り）ファイルの更新なんか検知しないのが普通

> メタ情報にも齟齬が発生する。
最初からこれが原因だって言ってる。Windowsアプリから保存すると、
（WSL用のメタデータを考慮してないほぼすべてのアプリは）
ファイル保存時にメタ情報が抜け落ちる。それだけでいい話

> 「実際の読み書きは土台のWindowsがやっているのだからファイルやメタ情報が壊れる訳がない」と繰り返しているアホは
誰もそんなこと言ってない。お前が
> オフライン中に別環境からパーティションを半端に弄られたり、
とか意味不明なことを言ってるんだろ。パーティション関係ない。オフライン関係ない。別環境なんてものはない

俺は>>675の時点でちゃんと以下のように言ってる。
> これまで壊れていたのは、Windowsアプリが、WSL用に追加している
> ファイルのメタ情報を考慮してないからだよ。保存した時に抜け落ちる。

> 支障なくアクセスするためにはWSL環境が起動していなければならない理由もできていない訳だ。
WSL環境が起動してないなければならない理由をお前は何も言ってない。
メタデータを保存するだけならば、WSL経由にする必要はない。

救いようのないアホ。韓国に住んでるんだろうな。

クソ邪魔だからコテ使えよ
それか逝ね

名前がドットから始まるファイルを作成可能に 〜「Windows 10 19H1」Build 18342
https://forest.watch.impress.co.jp/docs/news/1170820.html

WSLのシンボリックリンクをデスクトップアプリのテキストエディタなどで開けばただのテキストファイルだし。

>>714
ディレクトリ配下を再帰検索する野良アプリを使っている人は要注意かも。
名前がドットから始まるターゲットをディレクトリ扱いする間違った実装してたらアウト。

なんでWindowsからいじっただけでEAまで飛ぶのかよくわからんのだが

>>717
Linux側のi-nodeに同期させる仕組みがないからでしょ。パフォーマンスが犠牲になる実装を避けるのは当然。

>>717
メモ帳みたいに同じファイルに上書きするんなら消えない
VSCodeとか上書き操作しても実際には別ファイルへの書き出し→元ファイルと入れ替えってやるから消える

>>716
今までエクスプローラー以外から作れなかったわけじゃないのにそんな馬鹿な実装アプリ使ってたら既に問題出てるでしょ

>>717
保存する時に、別名で作成→古いファイルを消す→名前を変更する
ということをやってるから。

一応安全な手段ではあるんだよ。
これだと途中でエラーが起きてもデータが消える可能性少ない
データ保存に比べて一瞬で終わる名前の変更だけできればいいからね

Linux側のi-node（笑）

またLinux側とかありもしないものを持ち出してる
知識が浅いと駄目だね

WindowsでfileIDの調べ方がわからんかったから調べたら予想通りだった。

WSLのstat ファイル名で表示されるInode番号は、
Windowsではfsutil file queryfileid ファイル名で表示される
ファイルID（の16進数を10進数にしたもの）だった

さっきも言ったけどLinux側のi-nodeに同期とか存在しないんだよ。
Linuxがそういう管理してるんじゃないんだから。っていうかLinuxなんていねぇ。いるのはNTカーネルだけだ。
単にAPIを変換してるだけなんだから、WSLからInodeを知ろうとしたらNTFSのFileIDを返すだけの話

WSLではVolFsがinodeを管理してるからWSLからみたらinodeは普通に見える。実体がどうとかは関係ない。
WSL上ではアプリケーションはlinuxとして動くわけだから重箱の隅をつついても仕方ないし、inodeもないと動かない。

>>723
問題はそこじゃなくて「Linux側のi-nodeに"同期"させる」って言ってるところだよ。
同期だよ。同期。まるで別にLinux環境というものが存在して、そっち側でinodeを
Windowsとは別で管理していて同期を必要としていると思っているのだろう。

>>721 >>722 で言ってることが変わっていってるのが面白い。
「さっきも言ったけど」とか記憶障害っぽい感じがする。
「自分が先に思いついた」とか発言してた人かな、ひょっとして。
お大事に。

確認した。VolFsでもDrvFsでもi-nodeとしてNTFSのFileIDが表示されてる

そもそもi-nodeっていうのはext4とそのお仲間が持ってるもので
reiserfsなどにはi-nodeは存在しない。すべてのファイルシステムが持ってるものじゃないし
Linuxが管理してるものでもない（WSLにLinuxなぞ存在しないが）

だけどLinuxで必要とされるから、reiserfsのファイルシステムドライバが
i-nodeをエミュレートして表示している。

NTFSもそれに近い。NTFSのドライバはFileIDとして返すわけだが、
VolFsやDrvFsへの変換レイヤー（WSLの一部）がNTFSのFileIDをi-nodeとして見せてるだけ
VolFsやDrvFsがi-nodeを管理してるわけじゃない。単に変換してるだけ。

>>725
変わってないし、何も言い返せないならレスしなくていいよ

結局、NTFSのFileIDがi-nodeとして使われるわけだから同期なんて必要ないのが分かるだろう？

単に保存時にメタ情報を考慮しているかどうか。
いまちょっと確認したんだが、atomから保存した場合、
FileIDは変化しなかったけど実行属性は消えていた。

メモ帳やvscodeだと保存した場合FileIDは当然同じとして、実行属性は残ったまま
（だから俺はatomからvscodeに乗り換えた）

だから保存する時に以前のメタデータをどうするか？という処理が別に必要なのだろう。

どのlinuxユーザーでファイルを操作していることにするかという要件定義の問題。
NTFSのアクセス管理との整合性を破綻させない工夫が必要なのはCygwinの頃からある話で、誰でもわかる。
長々書かなくていい。

> どのlinuxユーザーでファイルを操作していることにするかという要件定義の問題。

また今までの話と全く関係ない話を始めたなｗ

で、その要件定義が何だって？
その先をいえや

>>725
一番最初にi-node考えたのは俺やで？

そうか特許申請はしたか？

分かる人にしか分からないけど、アムロ・レイの父テム・レイみたいでかわいそう。

ワシがリナスにi-node教えたったんや。

vaxが1977年。UNIXはそれ以前だからね。
史実なら軽く還暦越えっしょ

i-nodeはワシが育てた

>>724
「Linux側のi-nodeに"同期"させる」ってことが理解できてないのはお前だけ。
inodeの実体がNTFSのFileIDであっても、知らないシステムが変更したIDとWSLが管理してるIDの整合性は取れない。
基本的にWSLサブシステムはWindowsのサブシステムとは互いに独立してるからカーネルは同じだとしても管理は別物。
共同で管理するには”特別な”実装が必要になる。

> 知らないシステムが変更したIDとWSLが管理してるIDの整合性は取れない。

え？なんで？ｗ
理由言ってみ。どういう場合に整合性が取れなくなるのか
具体的な名前書いてさぁ

> 基本的にWSLサブシステムはWindowsのサブシステムとは互いに独立してるからカーネルは同じだとしても管理は別物。
え？なんで？なんでサブシステムが別だと
管理まで別物になるの？
理由が全く書いてないじゃないｗ

ほんと適当な嘘書かないでくれないかなぁ（苦笑）

> 「Linux側のi-nodeに"同期"させる」ってことが理解できてないのはお前だけ。

証拠を見せてあげよう。

「Linux側のi-nodeに"同期"させる」ってことが理解できてる人
他にいるなら、その人はどういうことなのか説明してみせて


意味不明だから、説明できる人が誰も居ないだろう

i-nodeが正しく反映できてなかったらシステムコールのstat構造体を使うプログラムは全滅だよ。

linuxのアクセス権限はi-nodeから紐づいたデータなのでWindows側のFileIDでは対応できない。

i-nodeにせよFileIDにせよデータベースのキーのようなもので他のデータと紐づいていてシステムコールを通じて変更される。

>>742
これ。だからwslで編集したファイルはwindowsで触ってもよいが、逆はダメになる。
>>738
windowsが作成したファイルをwslが編集するのは非推奨になってる。それを知らないだけだろ。
>>739
マイクロカーネルの基本的な概念を知らないだけだろ。

wsl$経由でコピーするとパーミッションが維持されないな

cp相当にしといた方が良いような気が
フィードバックしとくか…

>>742
> linuxのアクセス権限はi-nodeから紐づいたデータなのでWindows側のFileIDでは対応できない。

だから（Linuxじゃなくて）WSLから見えるアクセス権限は
ファイルについてる単なるメタデータなんだよ。

WSLから見えるユーザーとかあれは仮想的に作ったもので本物のアクセス権限じゃない。
WSLでrootになったとしてもWindows上から見れば、ユーザーの権限のまま

実際のアクセス権限はNTカーネルによって行われる。
だからDrvFsとかでWSL上のrootになっても書き込めないファイルが有る

>>744
> windowsが作成したファイルをwslが編集するのは非推奨になってる。それを知らないだけだろ。

なっていない。そのためのDrvFsなんだし。

https://kledgeb.blogspot.com/2017/12/wsl-126-drvfslinux.html
> DrvFsとは
> 「DrvFs」は、WSL環境（Linux環境）にWindowsのボリュームをマウントし、
> LinuxからWindowsのファイルにアクセスできるようにする仕組みです。

ほんと適当な嘘ばかりつくよねｗ

>>741
> i-nodeが正しく反映できてなかったらシステムコールのstat構造体を使うプログラムは全滅だよ。

i-nodeはFileIDを使えばいいだけ
それより同期の話は何処にいった？ｗ

一体何を同期するのだろうか？
誰か答えてくれｗｗｗ

>>747
https://japan.zdnet.com/article/35132978/
これ。次期アップデートから。

>>749
それがどうしたの？
windowsが作成したファイルをwslが編集するのは非推奨とか書いてないわけだが
文章ちゃんと読めてるか？

>>750
それ別人だから。脳みそお花畑か。

>>751
だからそれがどうしたのって聞いてるわけだが？

そんな事知ってるし、なんのために持ち出してきたんだ？
俺に言うことじゃないだろって話。

薬を飲んでさっさと寝ろ。 ID:BojX55g6

>>753
お前には聞いてないｗ

わざわざ有志が作ったブツでマウントとかしなくてもext2/4が読み書きできる様になるのか
これは良アプデの予感

たまにでどころを覗くというのも悪くないですね。
ttps://blogs.msdn.microsoft.com/commandline/

ところで Fedora ってどうなっちゃったんでしょうｗ モジュラー関係で何かあるのかな...

dnfが動かんからなぁ
それを解決したFedoraRemixはMS以外から出てるけども

・設定ファイルの容量は数KBに満たない

これをいじろうとすると
・必要なHDDの容量が20GB必要
・文字のエンコード関係で壊れるかもしれない不安
・２０GBのインストール・アンインストール作業。時間が掛からないわけが

http://kasou-ken.seesaa.net/article/459488503.html
https://linuxfan.info/wslconfig
https://mongonta.com/f341-howto-update-under8gbdisk/

win鯖のシス管みたいなことを何が悲しくてせなあかんのかよく理解できない…

>>758
そんな間違えだらけで役に立たないページ見て何がしたいの？

>>759
その役に立たないページの修正情報をただで集めようと言う魂胆だろう

しかし、WindowsでLinuxのソフトが普通に使えるもんな。
凄い時代になったもんだ。

>>758
・テキストエディタやロケールを扱えない自己紹介・腐った情報の掲示
・初心者向けコマンド解説
・低スぺPC Winアプデ方法
win鯖のシス管と何が関係するのか…

Mecabで最新の辞書データを使おうと思ったらLinuxでビルドするしかないからねぇ。
WSLのおかげで実質的にWindowsでの作業だけで最新の辞書データを適用できるようになった。

https://github.com/neologd/mecab-ipadic-neologd

>>762
> win鯖のシス管と何が関係するのか…

win鯖のシス管をパソコンのサポートと勘違いしてるんだろう。
パソコンの設定をするのは、win鯖のシス管だ！

ヘルプデスク部隊とWin鯖管を混同してはいけない

この馬鹿に理解させる必要は無いよ、無理に教化を試みて無駄な労力を使う事はない。
こいつがダメな理由を、周囲の第三者に説明するだけでいい。最後にこいつの人格批判を添えてな。
始めたのは向こう側だからな、遠慮は要らんぞ？

Visual Studioからgccでユニットテストしたいとき。
WSLがあれば楽チン。

エラーが出て俺は試せなかったんだが、Windows SandboxでWSL使えるか教えてほしい。

・WSLを有効化するには要再起動
・Windows Sandboxは再起動を要する作業はサポートされない

再起動もそうだけど、どうやってSandboxの中でWSL有効にするの？
そもそもWindowsの機能が空なんだけど…
dismもパッケージサービスコマンドが丸ごと無い

19H1リリースされても無料で使えるんだろうか。
事実上の新バージョンに見えるけど。

>>770
あらあ、そうなのか・・・

WSLから /mnt/c/ 配下のファイルを編集しちゃまずいのか？

別にまずくはない

変な所でEOFを検知する事無い？

>>775
fgetc() の戻り値を char型変数で受け取ったに2000ペリカ

ubuntu 側のgrepがwindows側のファイルを探せない(途中で探索が終わる）
とかだから違うな

2000ペリカ直ちに振り込むように

ウイルス対策ソフトとかが原因では？
grep -nE ".*" で一行ずつ出力させてエラーが出る場所追いかけてみてはどうか。

Linuxというものを理解してないのか？
理解してないのはOSやコンピュータというべきか？

/mnt/cなんてちょっと特殊なファイルシステムとして
マウントされてるだけに過ぎないんだから、
意味不明なことにはならんよ。

mmapが腐ってるとかの可能性を考えていたんだが

/mnt/c/〜/rootfs/の下は見えないようになってるのね
やっぱりここを触られるのはNGなのか

sjis のファイルだと、UTF-8 の文字列と一致しないから、見つからないだけ

grep -ir '赤い糸' ./*

ファイル名は自動的に、UTF-8 に変換してくれるけど

UTF-8が普及する前はEUC-JPがよく使われていた。
そういう昔のEUC-JPで書かれたファイルを
UTF-8の端末からgrepしても同じように見つからない

SJISのファイルをgrepしたいなら、端末の文字コードをSJISにすればできるだろうが
デフォルトでその設定は入ってないだろうな。
nkfでも使ったほうが簡単

>>777
straceしろよ