アカウント名:
パスワード:
Cygwinのapt-cygの挙動が分かりやすいが、Windowsは現在使用中のファイルの更新ができない。つまりaptやbrewと違い、wingetでwingetの更新はできないし、Windows Terminalから呼び出したのならWindows Terminalの更新も失敗し、同様の理由からアンインストールも失敗する。いつもの再起動後に云々のメッセージダイアログが表示され、たかがひとつふたつのアプリの更新如きに再起動を要求されることだろう。セットアップを自動化したいのならDOS時代のSHARE.exeより続くファイル管理の仕方から修正しないとムリ。
逆だよ、Windowsでは古くからファイルのmandatoryな排他ロックが完全かつセキュアに実装されているが、伝統的なUNIX/Linuxでは実装されていなかったの（最近はいろいろ事情が違うが）。
ディスク上の実行ファイルや共有ライブラリだけ更新されても、実行中のプロセスが更新されるわけではない。実行プロセスを再起動せずに使い続けると、部分的に更新されたディスクファイルを読み取ることで、あらゆる予期しない不整合が発生する可能性がある。だからWindowsの方法はセキュアで正しいものだ。UNIX/Linuxの便利さは見せかけだけで、危険で不完全な方法だよ。
エンジニアとして二流なくせにウェーイ系ITムラ社会の風潮に乗せられて安易にWindows叩きなんかするから、こういう恥ずかしい批判をしてしまうのだ。
Windowsの場合、デフォルトでは排他ロックあるけど、排他ロックせずに開くことも可能なんだよな。EXEやDLLで、排他ロックかけずに動かすとかいう馬鹿なことを普通はしないってだけで。
一応、今のLinuxでもセキュア/ロバストであることを企図してるディストリビューションでは、プロセスモジュールは排他で開くから実行中のモジュール更新はできない。将来的には一般向けに使われうディストリビューションでも Windowsと同様な排他ロックが標準になってくだろうね。
ファイルをロックするのとファイル名をロックするのは別じゃん。「最近」がいつかは知らんけど、UNIXでも実行中のファイルは書き換えられなかったけどな。(実行中のファイルの名前で新たなファイルを作ることはできる)書き換えられるやつもあったのはたしか。
起動時に必要なファイル(=inode)をぜんぶ開いて保持してる状態で動いているなら成り立つけど、上にあるように、動作途中で開くやつ、がなくはないのがな...
# 動的プラグイン系とかだけど、# まれーに変なのもいる
なので、安心でいうとlock madantoryなほうが、いいかなと思ったりする# ただ更新の仕方が面倒くさい(下手なのもいる)のはあるので、利用者からは痛し痒し
IoTとか組み込みでの「全て自分の管理下」の不自由環境でもない限り、排他無しなんて危なっかしくてやってられんですなぁ。
GNU/Linuxはだいたいrm /bin/rmできるそれをどう優れてると宣うべきかは知らんが
rm /bin/rmができることと#3819560のいう「(実行中のファイルの名前で新たなファイルを作ることはできる)」はだいたい同じこと言っているのではないか。
rmというかunlink(2)がすぐにやることは親ディレクトリから当該ファイルのエントリを消すこと。その結果、とりあえず削除されたように見える。ただ、元のファイルがオープン中だったら、OSカーネルとディスク上にはまだファイルの実体が存在している。全部クローズされたら削除される。
なお、Windowsでも「実行中のファイルの名前で新たなファイルを作ることはできる」は一応実現できる。オープン中のファイルの削除はできないがリネームはできるので、リネームすれば元と同じ名前のファイルを新たに作成できる。リネームした古いファイルは後ほど適当なタイミングで削除すればよい。
だからそれはファイル名を操作しているだけで、ファイルは操作してないんだよ。
ファイルシステムの実装にも依存するが、ファイル削除でファイル名触る必要なんてないだろ。
Linuxだろうが差し替えて更新だとopen済みのファイルはreleaseされんし、されても困る。システム全体に更新を反映させるには、ファイルを使用していたプロセス全部落とすか、OS再起動しかない。
使用中のファイルを差し替えられるから再起動不要なんてのは、詭弁としか思えん。
システム全体に更新を反映させるには、ファイルを使用していたプロセス全部落とすか、OS再起動しかない。
実際そのとおり。ついでに言うと、最近のUbuntu Linuxでは（きっとDebian由来だろうけど）、パッケージマネージャでlibcやsystemdやカーネルなどを更新すると、/run/reboot-requiredという空ファイルを作って、再起動が必要なことを伝えてくる。さらに、その引き金になったパッケージを/run/reboot-required.pkgsに追記するので、これを見てもいい。
だからrmはファイル削除しないんだよ。
ディレクトリエントリの削除とでも言えば満足か？なんにせよファイル名なんて操作しない。
実行バイナリやライブラリを上書き更新する訳無いでしょ。差し替えが普通。> 部分的に更新されたディスクファイルを読み取るこんな事言いながら二流とか言っちゃう自信を顧みるべき。
OSの出自が違うから方針が違うだけだと思いますよ。
人間がログファイル眺めてたらサーバーのバックアップジョブが失敗するとかいややん。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲはアレゲを呼ぶ -- ある傍観者
パッケージ管理ツールの前にファイル管理の仕方からやり直せ (スコア:0)
Cygwinのapt-cygの挙動が分かりやすいが、Windowsは現在使用中のファイルの更新ができない。
つまりaptやbrewと違い、wingetでwingetの更新はできないし、Windows Terminalから呼び出したのならWindows Terminalの更新も失敗し、同様の理由からアンインストールも失敗する。
いつもの再起動後に云々のメッセージダイアログが表示され、たかがひとつふたつのアプリの更新如きに再起動を要求されることだろう。
セットアップを自動化したいのならDOS時代のSHARE.exeより続くファイル管理の仕方から修正しないとムリ。
Re:パッケージ管理ツールの前にファイル管理の仕方からやり直せ (スコア:1)
逆だよ、Windowsでは古くからファイルのmandatoryな排他ロックが完全かつセキュアに実装されているが、
伝統的なUNIX/Linuxでは実装されていなかったの（最近はいろいろ事情が違うが）。
ディスク上の実行ファイルや共有ライブラリだけ更新されても、実行中のプロセスが更新されるわけではない。
実行プロセスを再起動せずに使い続けると、部分的に更新されたディスクファイルを読み取ることで、あらゆる予期しない不整合が発生する可能性がある。
だからWindowsの方法はセキュアで正しいものだ。UNIX/Linuxの便利さは見せかけだけで、危険で不完全な方法だよ。
エンジニアとして二流なくせにウェーイ系ITムラ社会の風潮に乗せられて安易にWindows叩きなんかするから、
こういう恥ずかしい批判をしてしまうのだ。
Re:パッケージ管理ツールの前にファイル管理の仕方からやり直せ (スコア:1)
Windowsの場合、デフォルトでは排他ロックあるけど、排他ロックせずに開くことも可能なんだよな。
EXEやDLLで、排他ロックかけずに動かすとかいう馬鹿なことを普通はしないってだけで。
一応、今のLinuxでもセキュア/ロバストであることを企図してるディストリビューションでは、プロセスモジュールは排他で開くから実行中のモジュール更新はできない。
将来的には一般向けに使われうディストリビューションでも Windowsと同様な排他ロックが標準になってくだろうね。
Re: (スコア:0)
ファイルをロックするのとファイル名をロックするのは別じゃん。
「最近」がいつかは知らんけど、UNIXでも実行中のファイルは書き換えられなかったけどな。
(実行中のファイルの名前で新たなファイルを作ることはできる)
書き換えられるやつもあったのはたしか。
Re: (スコア:0)
起動時に必要なファイル(=inode)をぜんぶ開いて保持してる状態で動いているなら成り立つけど、上にあるように、動作途中で開くやつ、がなくはないのがな...
# 動的プラグイン系とかだけど、
# まれーに変なのもいる
なので、安心でいうとlock madantoryなほうが、いいかなと思ったりする
# ただ更新の仕方が面倒くさい(下手なのもいる)のはあるので、利用者からは痛し痒し
Re: (スコア:0)
IoTとか組み込みでの「全て自分の管理下」の不自由環境でもない限り、排他無しなんて危なっかしくてやってられんですなぁ。
Re: (スコア:0)
GNU/Linuxはだいたいrm /bin/rmできる
それをどう優れてると宣うべきかは知らんが
Re:パッケージ管理ツールの前にファイル管理の仕方からやり直せ (スコア:1)
rm /bin/rmができることと#3819560のいう「(実行中のファイルの名前で新たなファイルを作ることはできる)」はだいたい同じこと言っているのではないか。
rmというかunlink(2)がすぐにやることは親ディレクトリから当該ファイルのエントリを消すこと。その結果、とりあえず削除されたように見える。ただ、元のファイルがオープン中だったら、OSカーネルとディスク上にはまだファイルの実体が存在している。全部クローズされたら削除される。
なお、Windowsでも「実行中のファイルの名前で新たなファイルを作ることはできる」は一応実現できる。オープン中のファイルの削除はできないがリネームはできるので、リネームすれば元と同じ名前のファイルを新たに作成できる。リネームした古いファイルは後ほど適当なタイミングで削除すればよい。
Re: (スコア:0)
だからそれはファイル名を操作しているだけで、ファイルは操作してないんだよ。
Re: (スコア:0)
ファイルシステムの実装にも依存するが、ファイル削除でファイル名触る必要なんてないだろ。
Linuxだろうが差し替えて更新だとopen済みのファイルはreleaseされんし、されても困る。
システム全体に更新を反映させるには、ファイルを使用していたプロセス全部落とすか、OS再起動しかない。
使用中のファイルを差し替えられるから再起動不要なんてのは、詭弁としか思えん。
Re:パッケージ管理ツールの前にファイル管理の仕方からやり直せ (スコア:1)
システム全体に更新を反映させるには、ファイルを使用していたプロセス全部落とすか、OS再起動しかない。
実際そのとおり。ついでに言うと、最近のUbuntu Linuxでは（きっとDebian由来だろうけど）、パッケージマネージャでlibcやsystemdやカーネルなどを更新すると、/run/reboot-requiredという空ファイルを作って、再起動が必要なことを伝えてくる。さらに、その引き金になったパッケージを/run/reboot-required.pkgsに追記するので、これを見てもいい。
Re: (スコア:0)
だからrmはファイル削除しないんだよ。
Re: (スコア:0)
ディレクトリエントリの削除とでも言えば満足か？
なんにせよファイル名なんて操作しない。
Re: (スコア:0)
実行バイナリやライブラリを上書き更新する訳無いでしょ。差し替えが普通。
> 部分的に更新されたディスクファイルを読み取る
こんな事言いながら二流とか言っちゃう自信を顧みるべき。
Re: (スコア:0)
OSの出自が違うから方針が違うだけだと思いますよ。
人間がログファイル眺めてたらサーバーのバックアップジョブが失敗するとかいややん。