「すべてがファイルである」とは、デバイスでさえUnixおよびUnixライクなシステムでファイル名とパスを持っていることを意味し、これにより、性質に関係なく、さまざまなリソースで共通のツールを使用できることを知っています。しかし、それを私が使用した唯一の他のOSであるWindowsと対比することはできません。コンセプトについての記事をいくつか読んだことがありますが、開発者以外の人にとっては理解しにくいと思います。素人の説明は人々が必要としているものです！
たとえば、カードリーダーに接続されているCFカードにファイルをコピーする場合は、次のようなものを使用します
zcat name_of_file > /dev/sdb
Windowsでは、カードリーダーがドライバーとして表示されると思いますが、同様のことを行うと思います。では、「すべてがファイルである」という哲学は、ここでどのように違いを生むのでしょうか？
承認された回答：
「すべてがファイルである」というのはちょっとした気まぐれです。 「すべてがファイルシステムのどこかに表示される」というのはマークに近く、それでも、システム設計の法則よりも理想的です。
たとえば、Unixドメインソケットはファイルではありませんが、ファイルシステムには表示されます。 ls -l </ code> 属性を表示するドメインソケット、 chmodを介してアクセス制御を変更する 、および一部のUnixタイプのシステム（たとえば、macOSでLinuxではない）では、 cat 1つとの間のデータ。
ただし、通常のTCP / IPネットワークソケットは、Unixドメインソケットと同じBSDソケットシステムコールで作成および操作されますが、TCP/IPソケットはしません。 これが当てはまる理由は特にありませんが、ファイルシステムに表示されます¹。
ファイルシステムに表示される非ファイルオブジェクトのもう1つの例は、Linuxの / procです。 ファイルシステム。この機能は、カーネルのランタイム操作に関する詳細を、主に仮想プレーンテキストファイルとしてユーザースペースに公開します。多くの/proc エントリは読み取り専用ですが、多くの / proc も書き込み可能であるため、ファイルを変更できる任意のプログラムを使用して、システムの実行方法を変更できます。残念ながら、ここでも非理想性があります。BSDタイプのUnixは通常、 / procなしで実行されます。 、およびSystem V Unixは、 / procを介して公開する量が大幅に少なくなります。 Linuxよりも。
それをMSWindowsと対比することはできません
まず、オンラインや本で見つけることができる感情の多くは、ファイルI / Oに関するものであり、この点でWindowsが「壊れている」ということは時代遅れです。 WindowsNTはこれの多くを修正しました。
最新バージョンのWindowsは、Unixと同様に統合されたI / Oシステムを備えているため、 ReadFile（）を介してTCP/IPソケットからネットワークデータを読み取ることができます。 WindowsSockets固有のAPIWSARecv（）ではなく 、 あなたがしたい場合は。これは、一般的な read（2）を使用してネットワークソケットから読み取ることができるUnixWayとまったく同じです。 Unixシステムコールまたはソケット固有のrecv（2） call.²
それでもなお、Windowsは、2021年にさえ、この概念をUnixと同じレベルに引き上げることができません。Windowsアーキテクチャには、ファイルシステムからアクセスできない、またはファイルのように表示できない領域がたくさんあります。いくつかの例：
- ドライバー。
WindowsのドライバーサブシステムはUnixと同じくらい簡単にリッチで強力ですが、ドライバーを操作するプログラムを作成するには、通常、Windows Driver Kitを使用する必要があります。つまり、Cまたは.NETコードを作成する必要があります。
UnixタイプのOSでは、コマンドラインからドライバーに対して多くのことを実行できます。不要な出力を/dev / null にリダイレクトするだけであれば、ほぼ確実にこれを実行しています。 .³
- プログラム間コミュニケーション。
Windowsプログラムは相互に簡単に通信できません。
Unixコマンドラインプログラムは、テキストストリームとパイプを介して簡単に通信します。 GUIプログラムは、多くの場合、コマンドラインプログラムの上に構築されるか、テキストコマンドインターフェイスをエクスポートするため、同じ単純なテキストベースの通信メカニズムがGUIプログラムでも機能します。
- レジストリ。
Unixには、Windowsレジストリに直接相当するものはありません。同じ情報がファイルシステム全体に散在しており、そのほとんどは / etcにあります。 、 / proc および/sys 。
ドライバー、パイプ、およびWindowsレジストリに対するUnixの回答が「すべてがファイルである」と関係があることがわからない場合は、読み進めてください。
「すべてがファイルである」という哲学は、ここでどのように違いを生むのでしょうか？
上記の3つのポイントを詳しく説明します。
長い答え、パート1：ドライブとデバイスファイル
CFカードリーダーがE：として表示されているとします。 Windowsおよび/dev / sdcの下 Linuxでは。それはどのような実際的な違いをもたらしますか？
構文のわずかな違いだけではありません。
Linuxでは、 dd if =/ dev / zero of =/ dev / sdcと言うことができます / dev / sdcの内容を上書きします ゼロ付き。
それが何を意味するのか考えてみてください。ここに通常のユーザースペースプログラム（ dd（1） ）仮想デバイス（ / dev / zero ）からデータを読み込むように依頼しました ）そしてそれが読み取ったものを実際の物理デバイス（ / dev / sdc ）に書き込みます ）統合されたUnixファイルシステムを介して。 dd 特別なデバイスからの読み取りと特別なデバイスへの書き込みを認識していません。以下に示すように、通常のファイルでも、またはデバイスとファイルの組み合わせでも機能します。
E：をゼロにする簡単な方法はありません Windowsではドライブ。Windowsはファイルとドライブを区別するため、同じコマンドを使用してそれらを操作することはできません。最も近い方法は、[クイックフォーマット]オプションを使用せずにディスクフォーマットを実行することです。これにより、ほとんどがゼロになります。 ドライブの内容を確認しますが、その上に新しいファイルシステムを書き込みます。 したくない場合はどうなりますか 新しいファイルシステム？ディスクをゼロだけで埋めたい場合はどうすればよいですか？
寛大に、 E：に新しいファイルシステムが本当に必要だと言いましょう。 。 Windowsのプログラムでこれを行うには、特別なフォーマットAPIを呼び出す必要があります。⁴Linuxでは、OSの「フォーマットディスク」機能にアクセスするためのプログラムを作成する必要はありません。作成するファイルシステムタイプに適したユーザースペースプログラムを実行するだけです： mkfs.ext4 、 mkfs.xfs 、またはあなたは何を持っていますか。これらのプログラムは、ファイルシステムを任意のファイルまたは / devに書き込みます。 渡すノード。
mkfs Unixyシステムのタイププログラムは、デバイスと通常のファイルを人為的に区別することなくファイルで動作します。つまり、Linuxボックスの通常のファイル内にext4ファイルシステムを作成できます。
$ dd if=/dev/zero of=myfs bs=1k count=1k
$ mkfs.ext4 -F myfs
これにより、文字通り、現在のディレクトリに myfsと呼ばれる1MiBのディスクイメージが作成されます。 。その後、他の外部ファイルシステムのようにマウントできます：
$ mkdir mountpoint
$ sudo mount -o loop myfs mountpoint
$ grep $USER /etc/passwd > mountpoint/my-passwd-entry
$ sudo umount mountpoint
これで、 my-passwd-entryというファイルを含むext4ディスクイメージができました。 その中に、ユーザーの / etc / passwdが含まれています エントリ。
必要に応じて、その画像をCFカードにブラストできます：
$ sudo dd if=myfs of=/dev/sdc1
または、そのディスクイメージをパックしてメールで送信し、あなたのメディアに書き込むことができます。 USBメモリスティックなどの選択：
$ gzip myfs
$ echo "Here's the disk image I promised to send you." |
mutt -a myfs.gz -s "Password file disk image" [email protected]
Linux⁵では、ファイル、ファイルシステム、およびデバイスの間に人為的な区別がないため、これらすべてが可能です。 Unixシステム上の多くのものは ファイル、またはファイルシステムを介してアクセスされ、のように表示されます。 ファイル、または他の方法で十分にファイルのように見えるので、そのように扱うことができます。
Windowsのファイルシステムの概念は寄せ集めです。ディレクトリ、ドライブ、およびネットワークリソースを区別します。 3つの異なる構文があり、すべてWindowsでブレンドされています。Unixライクな .. FOOBAR パスシステム、 C：のようなドライブ文字 、および \ SERVERPATHFILE.TXTなどのUNCパス 。これは、単一の一貫した設計ではなく、Unix、CP / M、MS-DOS、およびLANManagerからのアイデアの付加であるためです。これが、Windowsファイル名に不正な文字が非常に多く含まれている理由です。
Unixには統一されたファイルシステムがあり、すべてが単一の共通スキームによってアクセスされます。 Linuxボックスで実行されているプログラムの場合、 / etc / passwdの間に機能的な違いはありません。 、 / media / CF_CARD / etc / passwd 、および / mnt / server / etc / passwd 。ローカルファイル、外部メディア、およびネットワーク共有はすべて同じように扱われます。⁶
Windowsは、上記のディスクイメージの例と同様の目的を達成できますが、非常に才能のあるプログラマーによって作成された特別なプログラムを使用する必要があります。これが、Windowsに非常に多くの「仮想DVD」タイプのプログラムがある理由です。 OSのコア機能がないため、ギャップを埋めるためのプログラムの人工的な市場が生まれました。つまり、最高の仮想DVDタイプのプログラムを作成するために多くの人々が競争しているということです。ループデバイスを使用してISOディスクイメージをマウントできるため、*ixシステムではこのようなプログラムは必要ありません。
関連：RealVNCがWindowsスケーリングオプションに基づいて表示をスケーリングしないようにするにはどうすればよいですか？
同じことがディスクワイププログラムのような他のツールにも当てはまりますが、これもUnixシステムでは必要ありません。 CFカードの内容を、ゼロにするだけでなく、取り返しのつかないほどスクランブルしたいですか？はい、 / dev / randomを使用します / dev / zeroの代わりにデータソースとして ：
$ sudo dd if=/dev/random of=/dev/sdc
Linuxでは、コアOSの機能が十分に機能するだけでなく、非常にうまく機能するため、広く使用されているため、このようなホイールを再発明し続けることはありません。 Linuxボックスを起動するための一般的なスキームには、上記のような手法を使用して作成された仮想ディスクイメージが含まれます。⁷
Unixが最初からTCP/IP I / Oをファイルシステムに統合していたとしたら、 netcatがなかったことを指摘するのは公正だと思います。 vs socat vs Ncat vs nc 混乱の原因は、Windowsでのディスクイメージングとワイプツールの急増につながるのと同じ設計上の弱点でした。許容できるOS機能の欠如です。
ロングアンサー、パート2：仮想ファイルとしてのパイプ
DOSにルーツがあるにもかかわらず、Windowsには豊富なコマンドラインの伝統がありませんでした。
これは、Windowsにがないということではありません。 コマンドライン、または多くのコマンドラインプログラムがないこと。最近のWindowsには、PowerShellと呼ばれる非常に強力なコマンドシェルもあります。
それでも、このコマンドラインの伝統の欠如のノックオン効果があります。 DISKPARTのようなツールを入手できます ほとんどの人がコンピュータ管理MMCスナップインを介してディスクのパーティション分割などを行うため、これはWindowsの世界ではほとんど知られていません。次に、パーティションの作成をスクリプト化する必要がある場合、 DISKPARTが見つかります。 他のプログラムによって動かされるように実際に作られたわけではありません。はい、一連のコマンドをスクリプトファイルに書き込んで、 DISKPART/Sスクリプトファイルを介して実行できます。 、しかしそれはオールオアナッシングです。 本当に そのような状況で欲しいのは、GNU partedのようなものです 、 parted / dev / sdb mklabel gptのような単一のコマンドを受け入れます 。これにより、スクリプトで段階的にエラー処理を行うことができます。
これはすべて「すべてがファイルである」と何の関係があるのでしょうか。簡単：パイプを使用すると、コマンドラインプログラムのI/Oが一種の「ファイル」になります。パイプは単方向のストリームであり、通常のディスクファイルのようにランダムアクセスではありませんが、多くの場合、違いは重要ではありません。重要なのは、2つの独立して開発されたプログラムを添付し、それらを単純なテキストで通信させることができるということです。その意味で、UnixWayを念頭に置いて設計された2つのプログラムは通信できます。
本当にファイルが必要な場合は、プログラムの出力をファイルに変換するのは簡単です。
$ some-program --some --args > myfile
$ vi myfile
しかし、「すべてがファイルである」という哲学がより良い方法を提供するのに、なぜ一時ファイルに出力を書き込むのでしょうか。そのコマンドの出力をviに読み込むだけの場合 エディターバッファー、 vi あなたのために直接それをすることができます。 viから 「通常」モード、たとえば：
:r !some-program --some --args
これにより、そのプログラムの出力がアクティブなエディタバッファの現在のカーソル位置に挿入されます。内部的には、 vi パイプを使用して、プログラムの出力を、代わりにファイルから読み取るために使用するのと同じOS呼び出しを使用するコードに接続しています。 ：r の2つのケースがあったとしても、私は驚かないでしょう。 —つまり、！がある場合とない場合です。 —どちらも、 viのすべての一般的な実装で同じ汎用データ読み取りループを使用していました 。そうしない正当な理由は考えられません。
これはviの最近の機能ではありません 、 また;それは明らかに古代のed（1）に戻ります テキストエディタ。⁸
この強力なアイデアは、Unixで何度も浮かび上がります。
この2番目の例として、私の muttを思い出してください。 上記の電子メールコマンド。これを2つの別々のコマンドとして記述しなければならなかった唯一の理由は、一時ファイルに*。gzという名前を付けたいということです。 、電子メールの添付ファイルに正しい名前が付けられるようにします。ファイルの名前を気にしない場合は、プロセス置換を使用して一時ファイルの作成を回避できたはずです。
$ echo "Here's the disk image I promised to send you." |
mutt -a <(gzip -c myfs) -s "Password file disk image" [email protected]
gzip -c の出力を変更することで、一時的なものを回避します FIFO（ファイルのようなもの）または / dev / fdに オブジェクト（ファイルのようなもの）。 （ / dev / fd なので、Bashはシステムの機能に基づいて方法を選択します どこでも利用できるわけではありません。）
この強力なアイデアがUnixに現れるさらに3番目の方法については、 gdbを検討してください。 Linuxシステムの場合。これは、CおよびC++で記述されたソフトウェアに使用されるデバッガーです。他のシステムからUnixにアクセスするプログラマーは、 gdbを調べます。 そして、ほとんどの場合、「うん、それはとても原始的だ！」と不満を持っています。次に、GUIデバッガーを探しに行き、存在するいくつかのデバッガーの1つを見つけて、楽しく作業を続けます。多くの場合、GUIが gdbを実行していることに気付くことはありません。 その下に、その上にきれいなシェルを提供します。プログラムがそのレベルで競合する必要がないため、ほとんどのUnixシステムで競合する低レベルのデバッガはありません。必要なのは、高レベルのツールがパイプを介して簡単に通信できる場合に、高レベルのツールのベースとなる1つの優れた低レベルのツールです。
これは、 gdbのドロップイン置換を可能にする文書化されたデバッガーインターフェイスがあることを意味します 、しかし残念ながら、 gdbの主要な競合相手 低摩擦の道をたどりませんでした。
それでも、少なくとも可能 その将来のgdb 置換は、コマンドラインインターフェイスのクローンを作成するだけで透過的にドロップします。 Windowsボックスで同じことを実現するには、交換可能なツールの作成者は、ある種の正式なプラグインまたは自動化APIを定義する必要がありました。つまり、通常のコマンドラインユーザーインターフェースと完全なプログラミングAPIの両方を構築するのは大変な作業であるため、非常に人気のあるプログラムを除いては発生しません。
この魔法は、普及しているテキストベースのIPCの恩恵によって起こります。
WindowsのカーネルにはUnixスタイルの匿名パイプがありますが、通常のユーザープログラムがコマンドシェルの外部でIPCにそれらを使用することはめったにありません。これは、Windowsには、最初にコマンドラインバージョンですべてのコアサービスを作成してからGUIを構築するという伝統がないためです。個別にその上。これにより、GUIなしではいくつかのことができなくなります。これが、Linuxと比較してWindows用のリモートデスクトップシステムが非常に多い理由の1つです。WindowsはGUIなしでは非常に使いにくいです。
対照的に、SSHを介してUnix、BSD、OS X、およびLinuxボックスをリモートで管理するのが一般的です。そして、それはどのように機能しますか？ SSHは、ネットワークソケット（ファイルのようなもの）を / dev / pty *の疑似ttyに接続します （これはファイルのようなものです）。これで、リモートシステムはUnix Wayとシームレスに一致する接続を介してローカルシステムに接続されるため、必要に応じてSSH接続を介してデータをパイプ処理できます。
この概念が今どれほど強力であるかを理解していますか？
パイプされたテキストストリームは、単方向であることを除いて、プログラムの観点からファイルと区別できません。プログラムは、ファイルから読み取るのと同じ方法で、ファイル記述子を介してパイプから読み取ります。 FDはUnixの中核です。ファイルとパイプが両方のI/Oに同じ抽象化を使用しているという事実は、何かを教えてくれるはずです。⁹
単純なテキスト通信のこの伝統を欠いているWindowsの世界は、COMまたは.NETを介したヘビーウェイトのOOPインターフェースに対応しています。このようなプログラムを自動化する必要がある場合は、COMまたは.NETプログラムも作成する必要があります。これは、Unixボックスにパイプを設定するよりもかなり難しいです。
これらの複雑なプログラミングAPIがないWindowsプログラムは、クリップボードやファイル/保存の後にファイル/開くなどの貧弱なインターフェイスを介してのみ通信できます。
ロングアンサー、パート3：レジストリと構成ファイル
WindowsレジストリとUnixWayのシステム構成の実際的な違いは、「すべてがファイルである」という哲学の利点も示しています。
関連：1809でWindows 10 Wifiホットスポットが自動的にオフになるのを防ぎますか？Unixタイプのシステムでは、ファイルを調べるだけで、コマンドラインからシステム構成情報を確認できます。同じファイルを変更することで、システムの動作を変更できます。ほとんどの場合、これらの構成ファイルは単なるプレーンテキストファイルです。つまり、Unix上の任意のツールを使用して、プレーンテキストファイルで機能する構成ファイルを操作できます。
レジストリのスクリプトは、Windowsではそれほど簡単ではありません。
最も簡単な方法は、あるマシンのレジストリエディタGUIを使用して変更を加え、 regeditを使用してそれらの変更を他のマシンに盲目的に適用することです。 *。reg経由 ファイル。条件付きで何もできないため、これは実際には「スクリプト」ではありません。すべてかゼロかです。
レジストリの変更にある程度のロジックが必要な場合、次に簡単なオプションはPowerShellを学習することです。これは、基本的に.NETシステムプログラミングの学習に相当します。 UnixにPerlしかなく、すべてのアドホックを実行する必要がある場合のようになります。 それを介したシステム管理。今、私はPerlファンですが、誰もがそうであるわけではありません。 Unixでは、プレーンテキストファイルを操作できる限り、好きなツールを使用できます。
脚注：
- プラン9は、この設計ミスステップを修正し、
/ netを介してネットワークI/Oを公開しました。 仮想ファイルシステム。
Bashには/dev / tcpと呼ばれる機能があります これにより、通常のファイルシステム機能を介したネットワークI/Oが可能になります。これはカーネル機能ではなくBash機能であるため、Bashの外部やBashをまったく使用しないシステムでは表示されません。これは、反例として、ファイルシステムを通じてすべてのデータリソースを表示することがなぜこれほど良い考えであるかを示しています。
- 「最新のWindows」とは、Windows NTとその直系のすべての子孫を意味します。これには、Windows 2000、すべてのバージョンのWindows Server、およびXP以降のすべてのデスクトップ指向バージョンのWindowsが含まれます。私はこの用語を使用して、DOSベースのバージョンのWindows、つまりWindows95とその直接の子孫であるWindows98とWindowsME、およびそれらの16ビットの前身を除外します。
後者のOSには統合I/Oシステムがないことで違いがわかります。 TCP /IPソケットをReadFile（）に渡すことはできません Windows95の場合。ソケットはWindowsSocketsAPIにのみ渡すことができます。 Andrew Schulmanの独創的な記事、Windows 95：このトピックをさらに深く掘り下げるためのものではないことを参照してください。
- 間違いありません、
/ dev / nullは、Unixタイプのシステム上の実際のカーネルデバイスであり、表面的には同等のNULのように、特殊なファイル名だけではありません。 Windowsで。
Windowsは、 NULの作成を阻止しようとしますが ファイルの場合、Windowsのファイル名解析ロジックをだまして、単なるトリックでこの保護を回避することができます。 cmd.exeでそのファイルにアクセスしようとした場合 またはエクスプローラー、Windowsはそれを開くことを拒否しますが、サンプルプログラムと同様の方法を使用してファイルを開き、同様のトリックを介して削除できるため、Cygwinを介して書き込むことができます。
対照的に、Unixでは rm / dev / nullを喜んで使用できます。 、 / devへの書き込みアクセス権がある限り 、そしてその場所に新しいファイルを再作成できます。その開発ノードは単なる別のファイルであるため、すべてトリックを使用する必要はありません。その開発ノードが欠落している間、カーネルのnullデバイスはまだ存在しています。 mknod を使用して開発ノードを再作成するまで、アクセスできません。 。
他の場所で追加のnullデバイス開発ノードを作成することもできます。/home / grandma / RecycleBinと呼んでもかまいません。 、nullデバイスの開発ノードである限り、 / dev / nullとまったく同じように機能します。 。
- 実際には2つあります Windowsの高レベルの「フォーマットディスク」API：
SHFormatDrive（）およびWin32_Volume.Format（）。
非常に…まあ…Windowsには2つあります ある種の理由。 1つ目は、Windows Explorerに通常の[ディスクのフォーマット]ダイアログボックスを表示するように要求します。これは、ユーザーがインタラクティブにログインしている間のみ、最新バージョンのWindowsで動作することを意味します。もう1つは、ユーザー入力なしでバックグラウンドで呼び出すことができます。しかし、Windows Server 2003までWindowsに追加されませんでした。そうです、Unixが mkfs を出荷した世界では、コアOSの動作は2003年までGUIの背後に隠されていました。 1日目から
1974年のUnixV5の私のコピーには、 / etc / mkfsが含まれています。 、4136バイトの静的にリンクされたPDP-11実行可能ファイル。 （Unixは1980年代後半まで動的リンケージを取得しなかったため、実際の作業をすべて実行している大きなライブラリがどこかにあるわけではありません。）そのソースコード—V5システムイメージに/ usr / source/s2として含まれています/mkfs.c —は完全に自己完結型の457行のCプログラムです。 #includeすらありません ステートメント！
これは、 mkfsが何であるかを調べるだけではないことを意味します 高レベルでは、40年前のケン・トンプソンと同じように、Unixが作成されたのと同じツールセットを使用して実験することができます。 Windowsで試してみてください。今日最も近い方法は、 2014で最初にリリースされたDOSソースコードをダウンロードすることです。 、これはアセンブリソースの山にすぎません。おそらく手元にない古いツールでのみ構築され、最終的には、1974年のUnixV5よりもはるかに強力ではないOSであるDOS2.0の独自のコピーを入手できます。
（なぜUnix V5について話すのですか？それはまだ利用可能な最も初期の完全なUnixシステムだからです。以前のバージョンは明らかに時間の経過とともに失われています。V1/ V2時代のUnixをつなぎ合わせたプロジェクトがありましたが、mkfsが欠落しているようです。 、上にリンクされたV1マニュアルページの存在にもかかわらず、それがいつかどこかに存在したに違いないことを証明しています。このプロジェクトをまとめている人は、 mkfsの現存するコピーを見つけることができませんでした 含めるか、 find（1）なしでファイルを見つけるのが苦手です 、これもそのシステムには存在しません。 :) ）
さて、あなたは「 format.comに電話するだけではいけない」と考えているかもしれません。 ？ Windowsではmkfsを呼び出すのと同じではありません Unixで？」残念ながら、いや、それは同じではありません。理由はたくさんあります：
- First, `format.com` wasn't designed to be scripted. It prompts you to "press ENTER when ready", which means you need to send an Enter key to its input, or it'll just hang.
- Then, if you want anything more than a success/failure status code, you have to open its standard output for reading, which is [far more complicated on Windows than it has to be](http://msdn.microsoft.com/en-us/library/windows/desktop/ms682499%28v=vs.85%29.aspx). (On Unix, everything in that linked article can be accomplished with a simple [`popen(3)`](http://linux.die.net/man/3/popen) call.)
- Having gone through all this complication, the output of `format.com` is harder to parse for computer programs than the output of `mkfs`, being intended primarily for human consumption.
- If you trace what `format.com` does, you find that it does a bunch of complicated calls to [`DeviceIoControl()`](http://msdn.microsoft.com/en-us/library/windows/desktop/aa363216%28v=vs.85%29.aspx), `ufat.dll`, and such. It is not simply opening a device file and writing a new filesystem onto that device. This is the sort of design you get from [a company that employs 126000 people](https://news.microsoft.com/facts-about-microsoft/#EmploymentInfo), and needs to *keep* employing them.
-
ループデバイスについて話すときは、Unixタイプのシステム間でループデバイスを移植できないため、一般的にはUnixではなくLinuxについてのみ話します。 OS X、BSDなどにも同様のメカニズムがありますが、構文は多少異なります。
-
ディスクドライブが洗濯機のサイズであり、部門長の高級車よりも高価だった時代には、大規模なコンピューターラボは、最新のコンピューティング環境と比較して、集合的なディスクスペースの大部分を共有していました。リモートディスクをローカルファイルシステムに透過的に移植する機能により、このような分散システムははるかに使いやすくなりました。ここで
/usr / shareを取得します 、たとえば。
対照的なWindows。通常、リモートディスクはドライブ文字にマップされるか、ローカルファイルシステムに透過的に統合されるのではなく、UNCパスを介してアクセスする必要があります。ドライブ文字は、記号表現の選択肢をいくつか提供します。 P：を実行します BigServerの「パブリック」スペース、またはソフトウェアミラーサーバーの「packages」ディレクトリを参照してください。 UNCパスは、リモートファイルがどのサーバー上にあるかを覚えておく必要があることを意味します。これは、数百または数千のファイルサーバーがある大規模な組織では困難になります。
Windowsは、2007年にリリースされたWindows VistaがNTFSシンボリックリンクを導入するまで、シンボリックリンクを取得しませんでした。 Windowsのシンボリックリンクは、ローカルパスだけでなく、リモートファイル共有を指すこともできるという点で、Unixのシンボリックリンク（1977年以来のUnixの機能）よりも少し強力です。 Unixは、1984年にNFSを介してそれを別の方法で行いました。これは、Unixの既存のマウントポイント機能の上に構築されており、最初から持っていました。
関連：LFのないXMLは、シェルでsedコマンドを使用してきれいにしたいですか？したがって、見方にもよりますが、WindowsはUnixに約20年または30年遅れをとっています。
それでも、いくつかの理由から、シンボリックリンクはWindowsユーザーエクスペリエンスの通常の部分ではありません。
まず、後方コマンドラインプログラム MKLINKでのみ作成できます。 。 Windowsエクスプローラーから作成することはできませんが、Windowsエクスプローラーに相当するUnixは通常作成します。 シンボリックリンクを作成できます。
次に、デフォルトのWindows構成では、通常のユーザーがシンボリックリンクを作成できないため、管理者としてコマンドシェルを実行するか、平均的なユーザーが見たこともない、ほとんど知らないツールのあいまいなパスを介してコマンドシェルを作成する権限をユーザーに与える必要があります。使い方。 （そして、Windowsのほとんどの管理者特権の問題とは異なり、この場合、UACは役に立ちません。）
-
Linuxボックスは、起動シーケンスで常に仮想ディスクイメージを使用するとは限りません。それを行うにはさまざまな方法があります。
-
man ed -
ちなみに、ネットワークソケット記述子もその下にあるFDです。