【Bash】Windows Subsystem for Linux【WSL】3
レス数が1000を超えています。これ以上書き込みはできません。
Announcing Windows 10 Insider Preview Build 18277
https://blogs.windows.com/windowsexperience/2018/11/07/announcing-windows-10-insider-preview-build-18277/
> We fixed the issue causing WSL to not work in Build 18272. Thanks for your patience. Microsoft Storeにて2種類のLinuxディストロが配信開始
https://pc.watch.impress.co.jp/docs/news/1152338.html
Windows 10上でのLinuxの動作をサポートする「Windows Subsystem for Linux(WSL)」機能への追加Linuxディストリビューションの配信をMicrosoft Storeで開始した
配信が開始されたのはWLinux、OpenSUSE 15/SLES 15の2種類。
WLinuxに関しては有償での配布で価格は2,350円となっているが、現在期間限定で1,150円で販売されている。
このほか、ARM版Windows 10上のWSLにおけるUbuntu 18.04の動作が新たにサポートされ、
エクスプローラ上のコンテキストメニューからLinuxシェルが開けるようになったり、コンソール上でのコピーアンドペーストが使えるようになったりと、細かな機能追加もされている。 WLinuxなら自分で入れれば良いと思うんだけどな
githubで公開されてるんだから
特別なものでもなく中身Debianだし 何言ってんだも何も無料で入れられるって言ってるんだが? 「何言ってっだ」という東北なまり?に微妙に心が安らぐ。 WLinuxが記事になってる時、東南アジアにいて、Windowsの国と地域の設定を東南アジアの国にしてたせいか、WLinuxが100%割引になってたんよね
それで買った -OyomiオプションつきでWSL版mecabで開いた状態だと、Windows版mecabで同じ辞書フォルダを開けない。
Windows側でCreateFile()の共有指定をFILE_SHARE_READからFILE_SHARE_READ | FILE_SHARE_WRITEに変更して再ビルドすることで回避できた。
同じ問題が、いろんなアプリで起きそうな予感。
WSLで読み取りで開いているファイルにアクセスできないWindowsアプリとか潜在的に多そう。
ちなみにMSのCライブラリだとfopen(filename, "r") でFILE_SHARE_READ | FILE_SHARE_WRITEが指定されるので大丈夫。
CreateFile()というWindows固有のWin32APIを直接呼び出すコードで問題が起きる可能性がある。
読み取りで開くからといって共有指定をILE_SHARE_READ | FILE_SHARE_WRITE ではなくFILE_SHARE_READだけにするとハマる。 説明補足。Mecabは、オープンソース 形態素解析エンジン。
以下URLが公式。多分。
http://taku910.github.io/mecab/
>>984 で再ビルドしたってのはソースを修正してmecabバイナリ群をリビルトしたという意味。
CreateFile()を呼び出している箇所は一ヶ所だけなので修正はさほど手間ではない。
開発者の方には、そろそろMecabの最新版を公式リリースしてもらいたい。64bit対応とかあるだろうし。
なお、Mecabの最終更新が2013-02-18と5年以上前。
Mecabに限らず、WSLとWindowsで同時にファイルを開くアプリは要注意。
Bzという割とメジャーなバリナリエディタもCreateFile()の共有指定がFILE_SHARE_READだけなので同じ現象が起きる。
この件、WSLの仕様がおかしいようにも思える。 WSLのファイルシステムかメタデータ周りの問題かもな。
WSLなんて所詮オマケみたいなもんだ。遊びでしか使えん。 >>986
えとさ、安全かどうかでちゃんと考えてる?
読み取りで開いているって言ってるけど、
読み取り専用じゃねーからな。読み込み共有モードだからな
私は読み取りしかしない!と宣言してファイルを開いた時
その他のプロセスが書き込みしたら、一回目に読み取ったときと
二回目に読み取ったときでデータが変わってしまう
FILE_SHARE_READっていうのは自分が読み込みしかしない!と
宣言することじゃない。自分は書き込まないから他の人が読み込んでも
いつだって同じデータが読み取れるよ。
他の人は書き換えないと宣言するなら、読み取ってOKって言ってることになる。
同様にFILE_SHARE_WRITEは、自分はうまいことやるから
他の人書き込んでもOK!っていうことだ。
つまりは、自分は読み込みしかしないが他人に書き換えられたら困る!
ってときはFILE_SHARE_READだけにするんだよ
たいていは読み込み途中に書き換えられたら困るだろう?
mecabは他人に書き換えられてもOKと言ってるのか? 自分は読み取りしかしない!と宣言していても、
他人に書き換えられても大丈夫ってことにはならないからな Bzでの再現手順教えてくださいな
wsl上のemacsでc:/wsl/test.txtを開いたまま
win上のBz162でc:/wsl/test.txt開いてみたけど
問題なく開けるのでどうすればいいのかわからない >>988
書き込み側、読み込み側、どちらかが優先されるべきかは
それはアプリ次第であって、こうすべきと決めつけるものでもないでしょう。
起動中の読み取りアプリを犠牲にしてでも書き込み優先するという割り切り方もある。
>>990
後学のためにmecabをインストールしてみては? >>991
mecabでの再現の手順教えてもらえますか?
それよりはBzのほうが簡単だと思ったので、Bzで訪ねたんですけど >>992
以下のプログラムをWSLでコンパイルし、第一引数に開きたいファイルパスを渡して実行してください。
次に、Windows側で同じファイルをBzで開こうとすれば再現します。なお、当方は64bit版Windows10。
使っているWSLはUbuntu 18.04.1 LTS
#include <cstdio>
#include <unistd.h>
#include <fcntl.h>
#include <sys/mman.h>
int main(int argc, char* argv[])
{
const char* filename = argv[1];
int fd = ::open(filename, O_RDONLY);
int prot = PROT_READ;
char *p = reinterpret_cast<char *>(::mmap(0, 1024, prot, MAP_SHARED, fd, 0));
printf("%s %d %p\n", filename, fd, p);
fputs("input [ENTER].\n", stdout);
fgetc(stdin);
::close(fd);
fputs("bye.", stdout);
return 0;
} >>993
ありがと
wsl内部でファイルをreadonlyで開いても、windows側からはSHARE_RWで開いたとみなされて
SHARE_Rだけのcreatefileだとコケるという話ですね
fall 2018 updateでwslfsへ変換した環境でも再現できた >>988
> えとさ、安全かどうかでちゃんと考えてる?
たかが読み取りオンリーなプログラムの分際で、自分の安全しか考えない身勝手なプログラムはダメでしょう。
読み取り側が排他ロックしたい時だけロックするべきで、それ以外の時は書き込み側を優先するのが基本でしょう。 スキルの低い人ほど宗教的な信条を他人に押し付けたがる法則 スキルの低さを宗教的な信条で補っているともいえる。 このスレッドは1000を超えました。
新しいスレッドを立ててください。
life time: 157日 12時間 21分 7秒 レス数が1000を超えています。これ以上書き込みはできません。