[過去ﾛｸﾞ] 【Bash】Windows Subsystem for Linux【WSL】4 (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
596(1): 2019/02/10(日)14:42 ID:4QB1ehvb(4/6) AAS
>>595
それもDOSやWindowsのせいだろ。
597: 2019/02/10(日)14:49 ID:vNdhNpKg(1) AAS
SJISは改元後の合字に対応しないとMSは言ってるね
598(1): 2019/02/10(日)14:51 ID:VL8Y7mI7(2/3) AAS
>>596
韓国人じゃあるまいし、誰が悪いかを言いつのったって現状は変わらないよ？
599: 2019/02/10(日)15:03 ID:PpRunXVK(1) AAS
>>594
これでシステムはUTF-8になる
アプリのLive5chとかはunicodeサポートされてないのでメニューとかが文字化けした
ChromeやFirefoxは問題なかった
600(1): 2019/02/10(日)15:05 ID:4QB1ehvb(5/6) AAS
>>598
じゃあどうする？
代案も示さないようじゃ反論にもならない。
601: 2019/02/10(日)15:44 ID:VL8Y7mI7(3/3) AAS
>>600
SJIS続行。
602: 2019/02/10(日)16:34 ID:FKa3YLVf(1/2) AAS
Windowsと関係ないやん。
Windowsなんてとっくにネイティブ文字コードがUnicodeになってるのに
アプリが無理やりレガシーな文字コード使ってるだけだろ
603: 2019/02/10(日)18:14 ID:ln1Iybi8(1/2) AAS
地域の設定にutf-8を使用というチェックボックスがあったんだけど、いつからかutf-8がデフォになって、ユニコード対応でないプログラムの言語という設定が出来てる。
メモ帳のデフォがutf-8になったあたりかもしれない。
604: 2019/02/10(日)18:17 ID:ln1Iybi8(2/2) AAS
C++20でchar8_tが入るので、utf-8サポートを標準に従った状態でサポートできるようになるよ。
なんでここまで引っ張ったんだろな。
605(5): 2019/02/10(日)18:49 ID:WDm55icm(1/3) AAS
いまやってるsjisの話がwslにどうつながるんですか
606: 2019/02/10(日)19:12 ID:0N9ZkDlF(1) AAS
つなげてみせようホトトギス。
607: 2019/02/10(日)19:16 ID:z/JOeCxw(1) AAS
>>605
wslので叩くwinAPIのフレーバーが増えるんじゃない？
ネイティブ互換性が増えるとか
608: 2019/02/10(日)19:36 ID:WDm55icm(2/3) AAS
GNU Octave をubuntu 18.04 (wsl)とVcXsrvで使っていて、qt + opengl のグラフィックスが動作しなかったが、-wglから-nowgl にして、LIBGL_ALWAYS _INDIRECT を設定しないようにしたら、表示するようになった。
しかし、他のソフトウェア(gnuplot のwxt terminal )でwarning がでるようになった。
でも、warning だから、我慢しよう。
609: 2019/02/10(日)19:40 ID:geQWKm0U(1) AAS
>>605
強引にこじつけるとWindowsとWSLで協調動作を行うプロセス間にWindowsサブシステム側の言語設定を無理無く馴染ませる事が出来るかという話
当然だがWSL上で動くプロセスはあくまでLinuxそのままだから言語設定はLANGかロカール系環境変数に依存するという部分は変えられない
610: 605 2019/02/10(日)21:25 ID:WDm55icm(3/3) AAS
ありがとう。
Windows でもMsys2入れて、winptyコンソールアプリをつかっている私にはあんまり関係ないことだということがわかりました。
611(1): 2019/02/10(日)21:36 ID:FKa3YLVf(2/2) AAS
そもそもLinuxはASCII互換の文字コードしか扱えないので
SJISやUTF-16などに対応するのは事実上無理だよ。
これはLinux側（カーネル及びアプリ）の制限
612: 2019/02/10(日)21:42 ID:7dDCFb2B(3/3) AAS
ほとんど使われないけどwcharなPOSIX関数はある
Windowsは逆にこっちを明示的に使うようにして従来のAPIはロケール依存のまま残したんだけど
613: 2019/02/10(日)23:36 ID:n+msPr2T(1) AAS
>>611
日本語にSHIFT_JISを採用したUNIX系でOSもあったしSHIFT_JISについてはアプリが頑張ればいいだけでLinuxカーネルの問題は無いだろう
614: 2019/02/10(日)23:38 ID:4QB1ehvb(6/6) AAS
たしか、Solarisは日本語ロケールがSJISだったはず。
615(1): 2019/02/10(日)23:44 ID:Pba8NVNb(1) AAS
Solarisの日本語デフォはEUCじゃなかったっけ？
HP-UXはSJISだったね
Linuxこんな理由らしい
外部ﾘﾝｸ[pdf]:www.ossforum.jp
616(1): 2019/02/11(月)03:00 ID:Ps2OaQo9(1) AAS
>新しい技術への挑戦を尊ぶLinuxの開発技術者
蓄積されたデータを継承・発展させていくことだって、新しい技術への挑戦だろうになあ。
当時のOSS界隈はマイクロソフトをFUDを多用するとか言ってたけど、
おまえらのやってることも同じじゃねーかという。
617: 2019/02/11(月)03:51 ID:zatSZo6K(1) AAS
>>616
FUDを多用するというFUDだろ。
618: 2019/02/11(月)05:35 ID:d3+ToDjg(1) AAS
こんなとこでケチをつけてるだけの人生よりよっぽど有意義だな
619: 2019/02/11(月)16:35 ID:NpmMErM/(1) AAS
>>615
カタカナの長音記号もまともに扱えていない文書を堂々と掲げられる心意気に敬服
620: 2019/02/11(月)17:50 ID:ZtR+FBW0(1) AAS
私の環境では、X サーバーを-nowglで立ち上げないとグラフィックスで不具合が生じることがあった。たぶん、環境依存たと思う。
621: 2019/02/12(火)18:27 ID:4VsEZ14Z(1) AAS
環境依存てすか。
622: 2019/02/12(火)21:52 ID:DMYzS7Ac(1) AAS
-wgl はwindowsのopenglのハードウェアアクセラレーションを使うのでそう書いた。でも、確証はないので、多分をつけた。
623: 2019/02/13(水)15:25 ID:6SJTT0hi(1) AAS
Windows 2000ぐらいに小さくて軽いWindows 10に
WSLだけ入れたいわ。
それ以外の付属モノは、全部要らん。
624: 2019/02/13(水)15:27 ID:4G6e8oIh(1) AAS
WinPEとか？
625: 2019/02/13(水)16:02 ID:Y7Jic1pE(1) AAS
Hyper-V Server 2019とかいいんじゃね？
WSL有効に出来るよ
626(1): 2019/02/14(木)09:02 ID:5KVcRxs9(1) AAS
外部ﾘﾝｸ[htm]:www.aoky.net
Microsoft Word が単なるワープロだったのはアイゼンハワー大統領の時代(50 年代)にまでさかのぼります。(笑)
しかし代わりに何があるでしょう？ Microsoft は実際試したことがあります。
「みんな機能を追加しすぎだと不平を言っている。ワープロだけのソフトを作ってやろうじゃないか。
シンプルで純粋な、Web ページ作成やデータベースのないやつを」。
それが現れました。Microsoft Write です。みなさんご存じないでしょう。大失敗でした。誰も買いませんでした。
私はこれを「SUVの原理」と呼んでいます。みんな必要もないパワーに取り囲まれているのが好きなんです。
データベースやWeb ページ作成機能なんて必要ないのに、こう言うのです。
「アップグレードしておこう。そのうち必要になるかもしれないからね！」
627: 2019/02/14(木)09:11 ID:9RW83sGl(1) AAS
それならもう普通にLinuxインストールすればいいだろ。
628: 2019/02/14(木)09:15 ID:J0H4smgD(1/2) AAS
アメリカンジョークはよくわからん
629(2): 2019/02/14(木)09:33 ID:XJsoGs1y(1) AAS
>>626
ワードパッドやろwin使いなら誰でも知ってるで
でも欲しいのはバイナリのリッチテキストじゃなくて
テキストをテキストのまま色付けや段落分けできる構造化エディタだったんだよなあ
htmlやcssがもっと手軽に扱えたら良かったんだろうけど
630: 2019/02/14(木)12:27 ID:J0H4smgD(2/2) AAS
>>629
3.1まではwrite、95からはwordpadだっけ（以降もスタブのwrite.exeはあるけど）
631(1): 2019/02/14(木)12:44 ID:+a5nWrXs(1/2) AAS
>>629
> テキストをテキストのまま色付けや段落分けできる構造化エディタだったんだよなあ
無理やで？
勝手に色がつくことは可能だが、
ユーザーが自由自在に色を付けることはできない
632: 2019/02/14(木)17:35 ID:HB1dMj/R(1) AAS
>>631
rtfがそんな感じ
633: 2019/02/14(木)17:59 ID:+a5nWrXs(2/2) AAS
そりゃテキストにメタ情報入れればできるやろな
634: 2019/02/14(木)21:34 ID:bxRo5yVT(1) AAS
絵文字には色を付けられるのに
変なの
635: 2019/02/14(木)22:49 ID:XtUeQN9O(1) AAS
文句はアンテナ○○○に言っとくれ♪
636(2): 2019/02/15(金)20:22 ID:4tPOtJVd(1) AAS
Skip Aheadで\\wsl$\登録名\のUNCパスで各ディストリのrootfsにアクセスできる機能が追加されたがchmodし直しは変わらんしWSL内のmountも正しく反映される、浅いパスぐらいしか利点を感じない
637: 2019/02/15(金)20:45 ID:rS2vFNZM(1) AAS
どうやってそんなの見つけるん？と思ったらエクスプローラーにペンギンがいやがった
638: 2019/02/15(金)21:52 ID:yopvpU0W(1/2) AAS
>>636
お、マジか。どういう実装なんだろう？
俺が前思っていたのはWindowsからはそうやってアクセスできる
内部的には（WSLレイヤーを介さずに）sambaプロトコルで
アクセスしているかのように見せかけるって方法で、
chmodに関しても設定でsamba相当の事ができるようにすれば
Windowsからsamba経由でアクセスしてるのと変わらない
実用性になるだろうって思ってた
639: 2019/02/15(金)22:03 ID:yopvpU0W(2/2) AAS
>>636
一応言っておくと、
利点は遅くてLinuxファイルシステムと完全な互換性がないdrvfsではなく
速くて互換性が高いlxfsに置いたファイルをWindows上から直接修正できること
drvfsとは違い、ディスク上のファイルを直接参照するのではなく
\\wslという仮想的なファイルシステム経由でアクセスするので
Windows上からのアクセスは遅くなるものの、
設計的にはchmodの問題などを回避できる余地がある
ってところかな
640(2): 2019/02/16(土)08:11 ID:4SkpCbtu(1) AAS
What’s new for WSL in Windows 10 version 1903?
外部ﾘﾝｸ:blogs.msdn.microsoft.com
641(2): 2019/02/16(土)08:35 ID:+AhNmo2h(1) AAS
>>640
Microsoft本気だな
Macに移ったユーザを取り戻せる
642: 2019/02/16(土)22:29 ID:SM9Nxf7u(1) AAS
>>641
そんなことは気にしてない。
643: 2019/02/16(土)22:36 ID:d0Zo9/dD(1) AAS
MS「Mac？ああ、マクドのことやな。」
644: 2019/02/16(土)22:39 ID:LGkAnLif(1/2) AAS
Macに移ったのってWeb系のスクリプター連中が主でしょ
あのへんの層は大して金にならないからMSはそれほど重視してないだろう
とはいえこのままだとWinがクラウド開発に向かないゴミのレッテルを貼られて稼ぎ頭のエンタープライズまで逃げる恐れがあったから、
そうなる前に開発者離れを食い止めたいんだろうな
645: 2019/02/16(土)23:07 ID:xTYnczey(1) AAS
Msをクラウドにシフトさせた現CEOも優秀だし、オープンソースの徹底化も英断だったんだなって。
646(1): 2019/02/16(土)23:28 ID:LGkAnLif(2/2) AAS
いやAzureだけは擁護できないわ
MSの客層的にWinのVMさえちゃんと動けば儲かるのはわかるけど、
マネージドサービスの品質があまりにも低すぎる
真面目にやる気ないんならお願いだからホスティング以外は全部撤退して開発環境だけ作っててほしい
647: 2019/02/17(日)08:03 ID:ZdUzbQjW(1) AAS
>>646
お前が擁護しようがしまいが、
AzureではLinuxも動くし、AWSの次に使われてる
クラウドであることは否定できない
外部ﾘﾝｸ:japan.zdnet.com
648: 2019/02/17(日)14:11 ID:Kca9Y6j/(1) AAS
うちはまだ1809だな。
649: 2019/02/17(日)15:01 ID:GnBPW+si(1) AAS
>>640
この兼ね合いでバックグラウンドプロセスが無い状態でWSLコンソール全部閉じてもkill -9 -- -1してもinitが終了しなくなったんでwsl.conf弄るときはwsl --terminateするなり忘れずにな
650: 2019/02/17(日)23:05 ID:9u1nKlcg(1) AAS
今はwslのフォルダにあるファイルを作るとアクセス権限が000のファイルになってしまうけど、Windows 10 version 1903で変更されるんだろうか。
651: 2019/02/17(日)23:29 ID:orUD8X9v(1) AAS
そういうわけじゃない
9Pサーバ使ってアクセスするかたち
652: 2019/02/18(月)00:43 ID:vgu3WlPA(1) AAS
直で触るんじゃないんだろう。
串を経由するようなもんだ
653: 2019/02/18(月)01:43 ID:Hx+0klHC(1/4) AAS
なるほどSambaみたいなもんかね。
654: 2019/02/18(月)02:27 ID:oJQ0Iy5j(1) AAS
fuseじゃねえの
655: 2019/02/18(月)12:28 ID:0qhVCZvi(1) AAS
FTPだろ
656: 2019/02/18(月)12:33 ID:bKuN73hl(1/2) AAS
NFSだろ
657: 2019/02/18(月)12:41 ID:dETlfCE6(1) AAS
DOKANだろ
658(1): 2019/02/18(月)13:17 ID:lYOWj990(1/2) AAS
この仕組は俺も前に考えたんだよね。
実装大変そうだからやらなかったけど。
そんとき、こういうアイデアはあるけど
MSは実装しないだろうなって思ってた。
だからやったたこと驚いた。
最近のMSはすごいよ
正しいことをちゃんとやる
659: 2019/02/18(月)13:50 ID:kD94OHGe(1) AAS
俺はなんとも思わんが
そのチョイと癇に触るような上からの物言いはやめたほうがいいと思うぞ
660: 2019/02/18(月)14:01 ID:lYOWj990(2/2) AAS
え？なんで？笑
661: 2019/02/18(月)15:14 ID:xQKiKBxf(1) AAS
いるいる
後出しジャンケンであーこれ俺が考えてたやつだわーって言う奴
662: 2019/02/18(月)15:23 ID:8XcONusW(1) AAS
本当に考えていたならギフハブに12H以内に公開してみたまえ
663: 2019/02/18(月)15:27 ID:bKuN73hl(2/2) AAS
ウリナラ起源ニダなんとか
664: 2019/02/18(月)15:38 ID:Hx+0klHC(2/4) AAS
アイディアだけならだれでも思いつく。責任ある立場の人が相応のコストをかけて実現できるかどうかに意味がある。
665: 2019/02/18(月)18:34 ID:r8CD25X7(1) AAS
ていうか、最初に考えたの俺だけどね。
666: 2019/02/18(月)18:37 ID:ZodpL3ci(1) AAS
別に、そのアイデアの実装が複数できていてもいい。
OSSならば、どちらかが淘汰されるか、
どちらも良くて、途中で方向性が変われば、
また違うソフトウェアとして、生き延びていくだけ。
要するに、アイデアを実際に実装するかどうかだ。
実装しなければ、なにもない。
667(1): 2019/02/18(月)22:07 ID:Hx+0klHC(3/4) AAS
そもそもWindows上にLinuxを共存させようと思った時点でファイルの見せ方について検討して当たり前でしょ。
「自分が最初に思いついた」とか、ネタなら面白くないし、本気ならヤバイ。心の病気だよ。
668: 2019/02/18(月)22:44 ID:8f6zgYdr(1/2) AAS
>>667
NT4の時代からService for Unix があったから
今から20年前にMicrosoftは実装してたんだけどね
(Linux互換ではなかったけど)。
>>658
の彼はいつ考え付いたんだろうね。
669(1): 2019/02/18(月)23:08 ID:Hx+0klHC(4/4) AAS
あー、SFU限定でファイルパスの大文字小文字を別物扱いできるようにするにはレジストリをいじるとかなんとかあったの思い出した。なつい。
670: 2019/02/18(月)23:32 ID:8f6zgYdr(2/2) AAS
>>669
ですね。ただ、大文字小文字で別物扱いがいいのか今でもよくわかりません。
昔は日本語ファイル名なんて考えられなかったし。
671: 2019/02/19(火)05:18 ID:ALypmLE8(1) AAS
FUSEの逆をやるのかと思ったが、それも違うのか。
読み書き自体はブリッジ経由で稼動中のWSLにやらせるので、動作していないWSLのファイルは読み書きできない。
逆に、WSL側が関知しない形で配下のファイルを読み書きされる事もないから、OS非稼動時に他の環境からパーティションを勝手に読み書きされた時に発生するような不具合も原理上ない、と。
多少のオーバーヘッドは発生するにせよ、利便性と安全性を両立できるなら歓迎だな。グッジョブと言わざるを得ない。
672: 2019/02/19(火)05:48 ID:/oCvcR3Z(1/5) AAS
ファイル自体はWSLでもOSが管理してるわけだし、
Linuxでも別プロセスが勝手に書き換えることはあるんだから
WSL稼働時しか修正できない理由はないと思うけどね
673(1): 2019/02/19(火)07:29 ID:AJoj5fE3(1) AAS
WSL環境から読み書きするファイルも最終的にはWindowsの管理下にあるが、これまではWindows側からWSL配下のファイルを読み書きした際はWSL上で動作するLinux環境側が関知できないまま書き換わり、最悪では破損する危険があった。
ブリッジを介し、WSL自身を経由してWindows側から安全に読み書きできる手段が構築されたのが今回。以前と同じではない。
674: 2019/02/19(火)08:12 ID:Em4vwS4i(1) AAS
AppDataにあるものを直接書き換えるのはNGのままだよ。
675(1): 2019/02/19(火)09:35 ID:/oCvcR3Z(2/5) AAS
>>673
> WSL上で動作するLinux環境側が関知できないまま書き換わり
どういうこと？ WSLはOSじゃないんだけど？
OSはWindowsそのもの。Linux環境なんてものはない。
これまで壊れていたのは、Windowsアプリが、WSL用に追加している
ファイルのメタ情報を考慮してないからだよ。保存した時に抜け落ちる。
9Pサーバー経由にすることでメタ情報を上手く保護している
676(1): 2019/02/19(火)09:51 ID:fDyLLUpm(1/4) AAS
「Linuxでも別プロセスが勝手に書き換えることはある」(=それで支障が発生する)とか眠い事言ってる奴が、他人を詰問する滑稽さ。
677: 2019/02/19(火)09:54 ID:fDyLLUpm(2/4) AAS
そのメタ情報は、WSL上のLinuxカーネル相当分とファイルサブシステムを経由することで、適切に保持される。
そのためのブリッジを設えたのが今回。
あと「WSLはOSじゃない」の下りとかまあ何もかも浅くてデタラメなので、小学校からやり直せ。
678(1): 2019/02/19(火)10:01 ID:BpIr988U(1) AAS
よくわかんないんだけど、Windows側のテキストエディタ使ってLinux側のファイルをガンガン変更してもOKになったりしたって事？
679: 2019/02/19(火)10:04 ID:fDyLLUpm(3/4) AAS
>>678
\\wsl$\ディストリ名\〜 というUNCパスでアクセスすればね。
users\appdata以下を直で弄ったら、これまでと同様にぶっ壊れる
680(2): 2019/02/19(火)10:07 ID:fDyLLUpm(4/4) AAS
Windows側からの操作は動作中のWSL(Linux)環境経由で読み書きするので、Linux上で「Linuxでも別プロセスが勝手に書き換えることはある」のと同じ扱いとなり、
オフライン中に別環境からパーティションを半端に弄られたり、あるいは動作中に介入されるような不味い事にはならない。
まあ「WSL稼働時しか修正できない理由はないと思うけどね」とか言い切っちゃってるアホには、ちょっと難しかったかな。
681: 2019/02/19(火)10:22 ID:Wy/XTkiQ(1) AAS
とりあえず、ダブスラのSambaみてえなパス構成でアクセスすりゃあサブシステム側のお目通りかなって安心安全な改変ができるってことやろぉ
682(1): 2019/02/19(火)11:38 ID:yllL5c3i(1) AAS
よく分からんがWSLはOSじゃないっていいたいだけちゃうんかと
毎回、WSLはOSじゃないけどWSL上で動作するLinuxプログラムの実行環境が〜
とか言わないといかんのか？
683: 2019/02/19(火)15:59 ID:/oCvcR3Z(3/5) AAS
>>676
お前理解してないんじゃね？
Linuxでも別プロセスがファイルを書き換えることはあるよ。当たり前。
それでアプリレベルで支障が出たとしても、ファイルシステムが壊れるわけじゃないんだよ。
支障のレベルをお前わかってないね。
684(1): 2019/02/19(火)16:01 ID:/oCvcR3Z(4/5) AAS
>>680
> オフライン中に別環境からパーティションを半端に弄られたり、あるいは動作中に介入されるような不味い事にはならない。
オフライン中に別環境からパーティションを半端に弄られると
Linuxは壊れるんか？
つまり別ディスクから起動して書き換えるってことに相当するんだが
それでファイルシステムが壊れることはないだろ
だいたいWSLでは「パーティションをいじる」ことはできない。
パーティションを管理してるのはOS（Windows）なんだから
すこしWSLのファイル管理を勉強したほうが良いよ。
LinuxじゃないんだからWSLがデバイスを直接管理したりしてないの
685: 2019/02/19(火)16:03 ID:/oCvcR3Z(5/5) AAS
>>682
> 毎回、WSLはOSじゃないけどWSL上で動作するLinuxプログラムの実行環境が〜
Linuxプログラムの実行環境なんてのも存在しない。仮想マシンじゃあるまいし。
単にLinuxのシステムコールをWindowsのカーネルAPIに置き換えてるだけ
カーネルから見れば、LinuxアプリもWindowsアプリも同じ環境で動作しているように見える。
686(1): 2019/02/19(火)17:12 ID:cz61eBmF(1) AAS
連投粘着ウザいよ
そんなに言いたいならTripでもつけてやってよ
別に論破する必要ないから、本屋でも行って1000年ROMってろ（ﾊﾅﾎｼﾞｰでいいし
687: 2019/02/19(火)18:50 ID:xqfwwFc8(1) AAS
>>686
ハイ論破。
688: 2019/02/19(火)22:39 ID:E1J20PdO(1) AAS
WindowsからLinuxファイルへのアクセスが可能に 〜「Windows 10 19H1」におけるWSLの改善
外部ﾘﾝｸ[html]:forest.watch.impress.co.jp
WindowsからLinuxのファイルにアクセスする仕組み（Windows 10 version 1903）
外部ﾘﾝｸ[html]:kledgeb.blogspot.com
689(1): 2019/02/20(水)00:57 ID:ZkCjGgl7(1/2) AAS
>>684
>オフライン中に別環境からパーティションを半端に弄られると
>Linuxは壊れるんか？
オンライン中に別システムからちょっかい出されたら壊れるだろそりゃ
壊れないケースもあるだろうけどさ
690: 2019/02/20(水)03:38 ID:RONh19vE(1) AAS
編集でなくてrobocopyとかxcopyで
%userprofile% を別のディスクにバックアップしても壊れるんやろか？
691(1): 2019/02/20(水)05:51 ID:Bb2FxLV3(1) AAS
WSL では、Windows 側のsjis のファイル名が、
Linux 側で見ると、自動的に、UTF-8 に変換されるのが、すごい！
692: 2019/02/20(水)10:59 ID:tqBzq0z5(1) AAS
もともとNTFSはUTF-16で、api使うときにシステムロケールに変換してるから、その延長でしょう。
693(1): 2019/02/20(水)11:20 ID:cfEFMWF/(1/3) AAS
>>689
> オンライン中に別システムからちょっかい出されたら壊れるだろそりゃ
だから別システムってなんだよ？
WSLのアプリはNTカーネル上の1プロセス。
単なる別プロセスでしかないんだが。
えとさぁ、WSL用の別のOSがいて、そっちがWindowsの制御外から
デバイスごと管理してるわけじゃないんだぞ？わかってんのか？
694: 2019/02/20(水)11:20 ID:cfEFMWF/(2/3) AAS
>>691
Windowsはファイル名をUTF-16で管理してるのだから
UTF-8と相互変換するのは簡単
695: 2019/02/20(水)11:39 ID:3xVdPi64(1/2) AAS
改行と引用ウザイ
引用マウントしたいならふたばでも行ってくれ
其れかいっそブログでも書いてここに貼っとけばエエやん。論争大好きマンなの？
696: 2019/02/20(水)11:47 ID:cfEFMWF/(3/3) AAS
はい。論争大好きここでマウント取りたいマンですよ？
697: 2019/02/20(水)12:12 ID:3Qbbcy+7(1) AAS
うわっキモ・・・
698: 2019/02/20(水)12:14 ID:3xVdPi64(2/2) AAS
ごめん、マジひくわー
699: 2019/02/20(水)18:35 ID:rPNn21v1(1) AAS
しかし考えてみたら凄いことだよな。
Windowsで普通にLinuxソフトが動くもんな。
700: 2019/02/20(水)19:02 ID:eCAQNCtt(1) AAS
ExplorerでShell芸が輝くわぁ…
ネイティブでウィンドウシステムサポートしたら、ユーティリティ系でもなければデスクトップ環境系のLinuxの需要下がるよな
まあそれでもxubuntuとかお古PCに入れるんだろうけど。
701(1): 2019/02/20(水)21:46 ID:ZkCjGgl7(2/2) AAS
>>693
別システムは別システムだよ
なんでWindows配下のプロセスの話になるんだよ
702(1): 2019/02/21(木)01:33 ID:X1aZ7k5F(1/17) AAS
>>701
やっぱりWSLが別システムだって思ってんのか？
同じシステム上で動いていて、単に使ってるAPIが違うだけだぞ
その証拠にタスクマネージャーで見ると、WSLで動いているプロセスが
Windowsプロセスと同じように見える
ファイルはWindows（というかNTカーネル）が管理していて
どちらからロックを掛けても、同じようにロックが掛かる
WSLにドライバは存在せず、Windowsと同じドライバが管理してる
ファイルシステムだってそう。WindowsだろうがWSLだろうが
共通のドライバによって管理されてる。
だからどちらからどのタイミングで使ってもファイルシステムが壊れることはない
Windowsから触って壊れるのはファイルシステムではなくWSL上のメタデータが保存されないってだけ
ファイルシステムからみれば壊れているわけじゃない
703(1): 2019/02/21(木)02:23 ID:BP5ivoCS(1) AAS
WSLとか関係なくない
DBとかでもデータファイル直でいじらんだろ
704(1): 2019/02/21(木)02:41 ID:R9NfxpXA(1) AAS
>>702
なんでWSLの話だと思い込んでるのかなあ。
705: 2019/02/21(木)03:22 ID:X1aZ7k5F(2/17) AAS
>>704
今までの話の流れとスレタイを見ろ
706: 2019/02/21(木)03:26 ID:X1aZ7k5F(3/17) AAS
>>703
それは全く別の話。
WSL起動中でないと書き込みができないから安全とか
意味不明なことを言ってるやつがいる。
（WSLが別システムだから？意味不明ｗ）
こっちは書き込みの安全性についてWSL起動中かどうかは関係ないといってる。
直接弄った時の安全性は、WSLの起動とは関係ないだろ？
707: 2019/02/21(木)03:28 ID:X1aZ7k5F(4/17) AAS
WSL起動中でないと書き込みができないのは
ファイルが壊れるとか別システム（笑）とかじゃなくて、
ストアアプリでファイルはそのアプリ用に隔離されてるから
直接ファイルを弄ることはセキュリティポリシーに反するからだろう
ファイル自体は同じOSが管理してるんだから壊れることはない
708: 2019/02/21(木)03:34 ID:X1aZ7k5F(5/17) AAS
>>680の何が間違ってるのか理解できてないようだから書いておくと
> Windows側からの操作は動作中のWSL(Linux)環境経由で読み書きするので、・・・(1)
> Linux上で「Linuxでも別プロセスが勝手に書き換えることはある」のと同じ扱いとなり、・・・(2)
この(1)が全く関係ない。
(2)のLinux上で「Linuxでも別プロセスが勝手に書き換えることはある」のと同じ扱い
になるのは、WSL（Linuxではない）環境経由だろうが、WSL環境以外だろうが同じ。
WSL環境以外から書き込んでも、(2)と同じ扱いになる。
だから(1)は全く関係ない。
709(1): 2019/02/21(木)13:52 ID:pcT7Cq0q(1) AAS
WSL側はWindows側の挙動を知りようがないから、appdata以下を直で弄られてもWSL上のLinux環境からは察知できず、メタ情報にも齟齬が発生する。
NTFS上のファイルとしては無事でも、WSL上のLinux環境からは破綻してしまっていたのがこれまで。
19H1ではWindows側にブリッジを作り、\\wsl$〜というUNCパスを使えば書き込み処理が起動中のWSL経由で行われ、WSL上のLinux環境からも関知される。
「実際の読み書きは土台のWindowsがやっているのだからファイルやメタ情報が壊れる訳がない」と繰り返しているアホは、この構造を理解できていない。
構造を理解できていないために、支障なくアクセスするためにはWSL環境が起動していなければならない理由もできていない訳だ。
無知で無能なくせに、やたらと攻撃的でマウント気質。まあ控え目に言ってクズ野郎ですな。
こちらとしても手加減する理由がないので、思う存分叩き伏せられる。
710: 2019/02/21(木)14:08 ID:AOOSCp45(1) AAS
環境とかシステムって単語使うとまた噛みつかれるで
厳密君の言葉尻チェックうるさすぎ
711: 2019/02/21(木)14:15 ID:X1aZ7k5F(6/17) AAS
>>709
なんでいちいち関係ない話を付け加えるんだ？
> WSL側はWindows側の挙動を知りようがないから、appdata以下を直で弄られてもWSL上のLinux環境からは察知できず
さも検知できれば大丈夫みたいな言い方をしてるけど、検知の有無は関係ない
そもそも（ファイル更新検知のためのAPIを使わない限り）ファイルの更新なんか検知しないのが普通
> メタ情報にも齟齬が発生する。
最初からこれが原因だって言ってる。Windowsアプリから保存すると、
（WSL用のメタデータを考慮してないほぼすべてのアプリは）
ファイル保存時にメタ情報が抜け落ちる。それだけでいい話
> 「実際の読み書きは土台のWindowsがやっているのだからファイルやメタ情報が壊れる訳がない」と繰り返しているアホは
誰もそんなこと言ってない。お前が
> オフライン中に別環境からパーティションを半端に弄られたり、
とか意味不明なことを言ってるんだろ。パーティション関係ない。オフライン関係ない。別環境なんてものはない
俺は>>675の時点でちゃんと以下のように言ってる。
> これまで壊れていたのは、Windowsアプリが、WSL用に追加している
> ファイルのメタ情報を考慮してないからだよ。保存した時に抜け落ちる。
> 支障なくアクセスするためにはWSL環境が起動していなければならない理由もできていない訳だ。
WSL環境が起動してないなければならない理由をお前は何も言ってない。
メタデータを保存するだけならば、WSL経由にする必要はない。
712: 2019/02/21(木)14:31 ID:G6fatQrd(1) AAS
救いようのないアホ。韓国に住んでるんだろうな。
713: 2019/02/21(木)14:46 ID:noKSeJYV(1) AAS
クソ邪魔だからコテ使えよ
それか逝ね
714(1): 2019/02/21(木)15:12 ID:M7OHfXtD(1) AAS
名前がドットから始まるファイルを作成可能に 〜「Windows 10 19H1」Build 18342
外部ﾘﾝｸ[html]:forest.watch.impress.co.jp
715: 2019/02/21(木)15:13 ID:DEUESkAi(1/9) AAS
WSLのシンボリックリンクをデスクトップアプリのテキストエディタなどで開けばただのテキストファイルだし。
716(1): 2019/02/21(木)15:17 ID:DEUESkAi(2/9) AAS
>>714
ディレクトリ配下を再帰検索する野良アプリを使っている人は要注意かも。
名前がドットから始まるターゲットをディレクトリ扱いする間違った実装してたらアウト。
717(3): 2019/02/21(木)15:49 ID:31A9yt7R(1) AAS
なんでWindowsからいじっただけでEAまで飛ぶのかよくわからんのだが
718: 2019/02/21(木)15:53 ID:DEUESkAi(3/9) AAS
>>717
Linux側のi-nodeに同期させる仕組みがないからでしょ。パフォーマンスが犠牲になる実装を避けるのは当然。
719: 2019/02/21(木)16:06 ID:/JGBEnv9(1) AAS
>>717
メモ帳みたいに同じファイルに上書きするんなら消えない
VSCodeとか上書き操作しても実際には別ファイルへの書き出し→元ファイルと入れ替えってやるから消える
>>716
今までエクスプローラー以外から作れなかったわけじゃないのにそんな馬鹿な実装アプリ使ってたら既に問題出てるでしょ
720: 2019/02/21(木)16:08 ID:X1aZ7k5F(7/17) AAS
>>717
保存する時に、別名で作成→古いファイルを消す→名前を変更する
ということをやってるから。
一応安全な手段ではあるんだよ。
これだと途中でエラーが起きてもデータが消える可能性少ない
データ保存に比べて一瞬で終わる名前の変更だけできればいいからね
721(1): 2019/02/21(木)16:13 ID:X1aZ7k5F(8/17) AAS
Linux側のi-node（笑）
またLinux側とかありもしないものを持ち出してる
知識が浅いと駄目だね
722(1): 2019/02/21(木)16:25 ID:X1aZ7k5F(9/17) AAS
WindowsでfileIDの調べ方がわからんかったから調べたら予想通りだった。
WSLのstat ファイル名で表示されるInode番号は、
Windowsではfsutil file queryfileid ファイル名で表示される
ファイルID（の16進数を10進数にしたもの）だった
さっきも言ったけどLinux側のi-nodeに同期とか存在しないんだよ。
Linuxがそういう管理してるんじゃないんだから。っていうかLinuxなんていねぇ。いるのはNTカーネルだけだ。
単にAPIを変換してるだけなんだから、WSLからInodeを知ろうとしたらNTFSのFileIDを返すだけの話
上下前次1-新書関写板覧索設栞歴
あと 280 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.029s