"Все - файл" - це трохи гліб. "Все з’являється десь у файловій системі " ближче до позначки, і навіть тоді це більше ідеал, ніж закон дизайну системи.
Наприклад, сокети домену Unix не є файлами, але вони відображаються у файловій системі. Ви можете ls -lв сокет домену відображати його атрибути, catдані в / з одного, змінювати його контроль доступу через chmodтощо.
Але, хоча звичайні мережеві розетки TCP / IP створюються та маніпулюють тими самими системними дзвінками BSD-розеток, що й сокети домену Unix, розетки TCP / IP не відображаються у файловій системі ¹, хоча немає особливо вагомих причин, що це повинно бути правдою.
Інший приклад нефайлових об’єктів, що з’являються у файловій системі, - це /procфайлова система Linux . Ця функція розкриває велику кількість деталей про роботу ядра в користувальницькому просторі , переважно як віртуальні звичайні текстові файли. Багато /procзаписів /procдоступні лише для читання, але багато також можна записати, тому ви можете змінити спосіб роботи системи за допомогою будь-якої програми, яка може змінювати файл. На жаль, тут ми знову маємо ненідеальність: Unixes типу BSD, як правило, працюють без/proc , а System V Unixes виставляє набагато менше, /procніж це робить Linux.
Я не можу протиставити це MS MS
По-перше, велика частина настроїв, які ви можете знайти в Інтернеті та в книгах про те, що Unix - це те, що введення / виведення файлів і Windows в цьому плані "зламані", є застарілими. Windows NT багато цього виправила.
Сучасні версії Windows мають уніфіковану систему вводу-виводу, як і Unix, тому ви можете читати мережеві дані з TCP / IP-розетки через, ReadFile()а не специфічний API Sockets Windows WSARecv(). Це точно паралельно шляху Unix , де ви можете читати з мережевого сокета або загальний read(2)системний виклик Unix, або виклик, характерний для recv(2)сокетів.
Тим не менш, Windows все ще не може прийняти цю концепцію на тому ж рівні, що і Unix, навіть тут у 2018 році. Є багато областей архітектури Windows, до яких не можна отримати доступ через файлову систему або не можна розглядати їх як файлоподібні. Деякі приклади:
Водії.
Підсистема драйверів Windows легко настільки багата і потужна, як і Unix, але для написання програм для управління драйверами, як правило, доводиться використовувати комплект драйверів Windows , що означає писати код C або .NET.
У ОС Unix типу ви можете багато зробити драйверам з командного рядка. Ви майже напевно вже зробили це, хоча б лише перенаправляючи небажаний вихід на /dev/null.³
Міжпрограмне спілкування.
Програми Windows не спілкуються між собою легко.
Програми командного рядка Unix легко спілкуються за допомогою текстових потоків та труб. Програми графічного інтерфейсу часто або будуються поверх програм командного рядка, або експортують текстовий командний інтерфейс, так що ті ж прості механізми зв'язку на основі тексту працюють і з програмами графічного інтерфейсу.
Реєстр.
У Unix немає прямого еквівалента реєстру Windows. Ця ж інформація розповсюджується по файловій системі, більшість її в /etc, /procі /sys.
Якщо ви не бачите, що відповіді драйверів, файлів і відповіді Unix в реєстрі Windows мають щось спільне з "все є файлом", читайте далі.
Як філософія "Все є файлом" має значення тут?
Я поясню це, розклавши детальніше свої три пункти вище.
Довга відповідь, частина 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 не потрібно писати програму для доступу до функціонального режиму «диска формату» ОС. Ви просто запустити відповідну програму для користувача простору для типу файлової системи ви хочете створити: mkfs.ext4, mkfs.xfsабо що у вас. Ці програми записують файлову систему в будь-який файл або /devвузол, який ви передаєте.
Оскільки mkfsпрограми типу в системах Unixy працюють над файлами, не роблячи штучних розмежувань між пристроями та звичайними файлами, це означає, що я можу створити файлову систему ext4 всередині звичайного файлу в моєму вікні Linux:
$ dd if=/dev/zero of=myfs bs=1k count=1k
$ mkfs.ext4 -F myfs
Це буквально створює образ диска на 1 МіБ у поточній папці, що називається myfs. Потім я можу встановити його так, як якщо б це була будь-яка інша зовнішня файлова система:
$ mkdir mountpoint
$ sudo mount -o loop myfs mountpoint
$ grep $USER /etc/passwd > mountpoint/my-passwd-entry
$ sudo umount mountpoint
Тепер у мене є образ диска ext4 з файлом, який називається my-passwd-entryв ньому, який містить запис мого користувача /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" you@example.com
Все це можливо в Linux⁵, оскільки немає штучного розрізнення між файлами, файловими системами та пристроями. Багато речей в системах Unix або є файлами, або доступ до них здійснюється через файлову систему, так що вони виглядають як файли, або якимось іншим чином виглядають достатньо схожими на файл, щоб їх можна було розглядати як такі.
Концепція файлової системи Windows - це мішанка; він робить різниці між каталогами, накопичувачами та мережевими ресурсами. Є три різні синтаксиси, всі вони поєднані в Windows: ..\FOO\BARсистема C:контурів у формі Unix, такі букви диска, як UNC-контури \\SERVER\PATH\FILE.TXT. Це тому, що це скорення ідей від Unix, CP / M , MS-DOS та LAN Manager , а не єдиного узгодженого дизайну. Ось чому в іменах файлів Windows так багато незаконних символів .
У Unix є уніфікована файлова система, до якої все доступно за єдиною загальною схемою. До програми , що працює на коробці Linux, немає функціональної різниці між /etc/passwd, /media/CF_CARD/etc/passwdі /mnt/server/etc/passwd. Локальні файли, зовнішні медіа та мережеві спільні файли трактуються однаково. Same
Windows може досягти подібних цілей, наведених вище на прикладі зображення мого диска, але вам доведеться використовувати спеціальні програми, написані незвично талановитими програмістами. Ось чому в Windows існує так багато програм типу "віртуальний DVD" . Відсутність основної функції ОС створило штучний ринок програм для заповнення прогалини, а це означає, що у вас є купа людей, які змагаються за створення найкращої віртуальної програми типу DVD. Нам такі програми не потрібні в системах * ix, оскільки ми можемо просто змонтувати зображення диска ISO за допомогою циклічного пристрою .
Те саме стосується інших інструментів, таких як програми для витирання дисків , які нам також не потрібні в системах Unix. Хочете, щоб вміст вашої CF картки було безповоротно скремовано замість просто нульового? Гаразд, використовуйте /dev/randomяк джерело даних замість /dev/zero:
$ sudo dd if=/dev/random of=/dev/sdc
У Linux ми не продовжуємо винаходити такі колеса, оскільки основні функції ОС не тільки працюють досить добре, вони працюють настільки добре, що їх використовують широко. Типова схема завантаження вікна Linux включає зображення віртуального диска лише для одного прикладу, створеного за допомогою таких методів, як я показую вище.⁷
Я вважаю, що справедливо зазначити, що якби Unix інтегрував TCP / IP введення / виведення в файлову систему з самого початку, ми не мали б netcatvssocat проти Ncatпроти безладу , причиною якого був той же дизайн , слабкість , які призводять до розповсюдження дискових зображень та протирання інструментів для Windows: відсутність прийнятної можливості ОС.nc
Довга відповідь, частина 2: Труби як віртуальні файли
Незважаючи на своє коріння в DOS, Windows ніколи не мав багатої традиції командного рядка.
Це не означає , що Windows , НЕ має командний рядок, або що йому не вистачає багатьох програм командного рядка. У наші дні Windows навіть має дуже потужну командну оболонку, яку належним чином називають PowerShell .
Тим не менш, є ефективні наслідки цієї відсутності традицій командного рядка. Ви отримуєте такі інструменти, DISKPARTякі майже невідомі у світі Windows, оскільки більшість людей займаються розділенням дисків і подібним способом за допомогою оснащення MMC управління комп'ютером. Тоді, коли вам потрібно сценарій створення розділів, ви виявите, що DISKPARTнасправді не було створено для того, щоб керуватися іншою програмою. Так, ви можете записати серію команд у файл скрипту і запустити його через DISKPART /S scriptfile, але це майже або нічого. Що ти насправді хочеться в такій ситуації, - це щось на кшталт GNUparted , який прийме одиничні команди на кшталт parted /dev/sdb mklabel gpt. Це дозволяє вашому сценарію здійснювати поводження з помилками поетапно.
Що все це стосується "все - це файл"? Легко: труби перетворюють програму вводу / виводу командного рядка у "файли" свого роду. Труби - це односпрямовані потоки , а не випадковий доступ, як звичайний файл диска, але в багатьох випадках різниця не має жодного наслідку. Важливим є те, що ви можете приєднати дві незалежно розроблені програми та змусити їх спілкуватися за допомогою простого тексту. У цьому сенсі будь-які дві програми, розроблені з урахуванням шляху Unix , можуть спілкуватися.
У тих випадках, коли вам дійсно потрібен файл, легко перетворити вихідний програму у файл:
$ some-program --some --args > myfile
$ vi myfile
Але навіщо писати вихід у тимчасовий файл, коли філософія "все є файлом" дає вам кращий спосіб? Якщо все, що ви хочете зробити, це прочитати вихід цієї команди в viбуфер редактора,vi можна зробити безпосередньо для вас. У режимі vi"нормальний" скажіть:
:r !some-program --some --args
Це вставляє вихід програми в активний буфер редактора в поточному положенні курсора. Під кришкою viвикористовується труби для підключення виводу програми до бітового коду, який використовує ті самі виклики ОС, які він використовує для читання з файлу. Я не був би здивований, якщо обидва випадки :r- тобто з і без !- обидва використовували один і той же загальний цикл зчитування даних у всіх поширених реалізаціях vi. Я не можу придумати вагомих причин цього не зробити.
Це теж не нещодавня особливість vi; це зрозуміло до стародавнього ed(1)текстового редактора.⁸
Ця потужна ідея з’являється знову і знову в Unix.
Для другого прикладу цього пригадайте мою muttкоманду електронної пошти вище. Єдина причина, що мені довелося написати, як дві окремі команди, це те, що я хотів, щоб тимчасовий файл був названий *.gzтак, щоб вкладення електронної пошти було правильно названо. Якби я не переймався іменем файлу, я міг би використати підстановку процесу, щоб уникнути створення тимчасового файлу:
$ echo "Here's the disk image I promised to send you." |
mutt -a <(gzip -c myfs) -s "Password file disk image" you@example.com
Це дозволяє уникнути тимчасового, перетворюючи вихід gzip -cу FIFO (який схожий на файл) або /dev/fdоб'єкт (який схожий на файл). (Bash вибирає метод, виходячи з можливостей системи, оскільки /dev/fdдоступний не скрізь.)
Ще третій спосіб, як ця потужна ідея з'являється в Unix, врахуйте gdb в системах Linux. Це налагоджувач, який використовується для будь-якого програмного забезпечення, написаного на C та C ++. Програмісти, що приходять в Unix з інших систем, дивляться на це gdbі майже незмінно всміхаються: "Юк, це так примітивно!" Потім вони шукають налагоджувач графічного інтерфейсу, знаходять одне з кількох, що існують, і радісно продовжують свою роботу ... часто ніколи не розуміючи, що графічний інтерфейс просто працює gdbпід ним, надаючи гарну оболонку поверх нього. Немає конкуруючих налагоджувачів низького рівня в більшості систем Unix, тому що програми не повинні конкурувати на цьому рівні. Все, що нам потрібно, - це один хороший інструмент низького рівня, на якому ми можемо базувати свої інструменти високого рівня, якщо цей інструмент низького рівня легко спілкується по трубах.
Це означає, що зараз у нас є задокументований інтерфейс налагодження, який би дозволив замінити gdbосновний конкурент, але, на жаль, основного конкурентаgdb не пішов на шлях низького тертя .
І все-таки, можливо , можливо , якесь майбутнєgdb заміна буде закриватися прозоро просто шляхом клонування його інтерфейсу командного рядка. Щоб витягнути те саме на вікні Windows, творцям змінного інструменту довелося б визначити якийсь офіційний API для плагіна або автоматизації. Це означає, що цього не відбувається, за винятком найпопулярніших програм, оскільки для роботи над створенням звичайного інтерфейсу користувача командного рядка та повного API програмування потрібно багато роботи.
Ця магія відбувається завдяки витонченості всеосяжного текстового IPC .
Хоча ядро Windows має анонімні канали у стилі Unix , рідко можна побачити, як звичайні користувацькі програми використовують їх для IPC поза командної оболонки, тому що Windows не вистачає цієї традиції створити спочатку всі основні служби у версії командного рядка, а потім побудувати графічний інтерфейс на зверху окремо. Це призводить до неможливості зробити деякі речі без графічного інтерфейсу, що є однією з причин того, що для ОС Windows існує стільки віддалених настільних систем , порівняно з Linux: Windows дуже важко використовувати без графічного інтерфейсу.
На відміну від цього, звичайно віддалено управляти скриньками Unix, BSD, OS X та Linux віддалено через SSH. І як це працює, запитаєте ви? SSH з'єднує мережевий сокет (який є файл-подібний) до псевдотермінали на /dev/pty*(який є файл-подібним). Тепер ваша віддалена система підключена до вашої локальної через з'єднання, яке так легко відповідає Unix Way, що ви можете передавати дані через SSH-з'єднання , якщо вам потрібно.
Чи отримуєте ви уявлення про те, наскільки потужна ця концепція зараз?
Трубопровідний текстовий потік не відрізняється від файлу з точки зору програми, за винятком того, що він односпрямований. Програма читає з труби так само, як і з файлу: через дескриптор файлу . FD є ядром Unix; той факт, що файли та труби використовують однакову абстракцію для вводу-виводу на обох, повинен щось вам сказати.⁹
Світ Windows, відсутній у цій традиції простого текстового спілкування, робить обробку з важкими інтерфейсами OOP через COM або .NET . Якщо вам потрібна автоматизація такої програми, ви також повинні написати програму COM або .NET. Це досить складно, ніж встановити трубу на коробці Unix.
Програми Windows, яким не вистачає цих складних API програмування, можуть спілкуватися лише через збіднілі інтерфейси, такі як буфер обміну або Файл / Зберегти, а потім Файл / Відкрити.
Довга відповідь, частина 3: Файли реєстру та конфігурації
Практична різниця між реєстром Windows та конфігурацією системи Unix Way також ілюструє переваги філософії "все є файлом".
У системах типу Unix я можу розглядати інформацію про конфігурацію системи з командного рядка, просто вивчаючи файли. Я можу змінити поведінку системи, змінивши ті самі файли. Здебільшого ці файли конфігурації - це просто текстові файли, а це означає, що я можу використовувати будь-який інструмент в Unix для управління ними, який може працювати з текстовими файлами.
Сценарій реєстру в Windows майже не такий простий.
Найпростіший метод - внести зміни на GUI редактора реєстру на одній машині, а потім сліпо застосувати ці зміни до інших машин за regeditдопомогою *.regфайлів . Це насправді не "сценарій", оскільки він не дозволяє вам робити що-небудь умовно: це все або нічого.
Якщо для зміни ваших реєстрів потрібна логіка, наступним найпростішим варіантом є вивчення PowerShell , що в основному означає вивчення системного програмування .NET. Було б так, якби в Unix був лише Perl, і ви повинні виконати всю адміністрацію системи ad hoc через нього. Зараз я шанувальник Perl, але не всі є. Unix дозволяє використовувати будь-який інструмент, який вам подобається, якщо він може маніпулювати простими текстовими файлами.
Виноски:
План 9 фіксованою конструкція цього невірний крок, піддаючи мережу введення / виведення з допомогою в /netвіртуальної файлової системи .
Bash має функцію під назвою,/dev/tcp яка дозволяє мережевий введення / виведення через звичайні функції файлової системи. Оскільки це функція Bash, а не функція ядра, вона не видно за межами Bash або в системах, які взагалі не використовують Bash . Це, за допомогою контрприкладу, показує, чому така хороша ідея зробити усі ресурси даних видимими через файлову систему.
Під «сучасним Windows» я маю на увазі Windows NT та всіх його прямих нащадків, що включає Windows 2000, усі версії Windows Server та всі версії Windows, орієнтовані на робочий стіл від XP. Я використовую цей термін, щоб виключити основані на DOS версії Windows, це Windows 95 та його прямі нащадки, Windows 98 та Windows ME, а також їхні 16-бітні попередники.
Ви можете помітити відмінність за відсутністю єдиної системи вводу / виводу в цих останніх ОС. Ви не можете передати TCP / IP-розетку в ReadFile()Windows 95; ви можете передавати сокети лише в API Sockets. Дивіться первинну статтю Ендрю Шульмана, Windows 95: Що це не для глибшого заглиблення в цю тему.
Не помиляйтесь, /dev/nullце справжній пристрій ядра в системах типу Unix, а не просто ім'я файлу зі спеціальним кейсом, як це поверхнево еквівалентNUL в Windows.
Хоча Windows намагається перешкодити вам створити NULфайл, цей захист можна обійти просто хитрістю , обдурити логіку розбору імені файлів Windows. Якщо ви спробуєте отримати доступ до цього файлу за допомогою « cmd.exeПровідника», Windows відмовиться відкривати його, але ви можете записати в нього через Cygwin, оскільки він відкриває файли, використовуючи подібні методи, наприклад, прикладну програму, і ви можете видалити його за допомогою подібної хитрості .
На противагу цьому, Unix із задоволенням дозволить вам rm /dev/null, доки ви маєте доступ до запису /dev, і дозволить вам відтворити на його місці новий файл, все без хитрощів, адже цей вузол розробника - це лише інший файл. Поки цього вузла розробки немає, нульовий пристрій ядра все ще існує; це просто недоступно, поки ви не будете відтворити вузол dev via mknod.
Ви можете навіть створити додаткові вузли dev nv dev-вузлів в іншому місці: не важливо, чи будете ви його викликати /home/grandma/Recycle Bin, якщо це вузол dev для нульового пристрою, він буде працювати точно так само, як /dev/null.
Насправді є два API високого рівня "дискового формату" в Windows: SHFormatDrive()і Win32_Volume.Format().
Є два дуже ... ну ... Windows -то причина. Перший просить Провідник Windows відобразити його звичайне діалогове вікно "Формат диска", що означає, що він працює у будь-якій сучасній версії Windows, але лише тоді, коли користувач інтерактивно входить у систему. але він не був доданий до Windows до Windows Server 2003. Правильно, основна поведінка ОС була прихована за графічним інтерфейсом до 2003 року, у світі, куди Unix постачався mkfs з першого дня .
Моя копія Unix V5 з 1974 року включає /etc/mkfsв себе виконуваний PDP-11 4136 байт статично пов'язаного . (Unix не отримав динамічних зв'язків до кінця 1980-х , тому це не так, як десь ще є велика бібліотека, яка виконує всі реальні роботи.) Його вихідний код - включений у зображення системи V5 як /usr/source/s2/mkfs.c- повністю автономний 457- програма C. Навіть їх немає#include тверджень!
Це означає, що ви можете не тільки вивчити, що mkfsробить на високому рівні, ви можете експериментувати з ним, використовуючи той самий набір інструментів, з яким створено Unix, як і ви, Кен Томпсон , чотири десятиліття тому. Спробуйте це з Windows. Найближчим до вас сьогодні може стати завантаження вихідного коду DOS , вперше випущеного у 2014 році , який ви вважаєте, що становить лише купу джерел складання . Він буде створюватися лише за допомогою застарілих інструментів, які ви, мабуть, не матимете під рукою, і врешті-решт ви отримаєте свою власну копію DOS 2.0, ОС набагато менш потужної, ніж Unix V5 1974 року , незважаючи на те, що вона була випущена майже десятиліття пізніше.
(Навіщо говорити про Unix V5? Тому що це найбільш рання повна система Unix, яка все ще доступна. Ранні версії, очевидно, втрачені часом . Був проект, який поєднав Unix епохи V1 / V2, але, здається, він відсутній mkfs, незважаючи на існування сторінки, пов’язаної вище з керівництвом V1, доказуючи, що вона, можливо, десь існувала, або ті, хто поєднує цей проект, не змогли знайти існуючу копію mkfsдля включення, або я засмоктую пошук файлів без find(1), яких також немає в цій системі .:) )
Тепер ви можете подумати: "Чи не можу я просто зателефонувати format.com? Хіба це не те саме в Windows, як дзвінок mkfsв Unix?" На жаль, ні, це не те саме, з низки причин:
По-перше, format.comне було розроблено для сценаріїв. Він запропонує "натиснути ENTER, коли готовий", а це означає, що вам потрібно надіслати клавішу Enter на його введення, або вона просто зависне.
Потім, якщо ви хочете щось більше, ніж код статусу успіху / невдачі, вам доведеться відкрити його стандартний вихід для читання, який набагато складніше в Windows, ніж це має бути . (У Unix все, що у цій пов'язаній статті, може бути виконано простим popen(3)дзвінком.)
Переживши все це ускладнення, вихід format.comскладніше для аналізу комп'ютерних програм, ніж вихід mkfs, призначений насамперед для споживання людиною.
Якщо простежити , що format.comробить, ви виявите , що вона робить купу складних викликів DeviceIoControl(), ufat.dllі тому подібне. Це не просто відкриття файлу пристрою та запис нової файлової системи на цей пристрій. Це такий дизайн, який ви отримуєте від компанії, в якій працює 126000 людей , і потрібно продовжувати їх використовувати.
Якщо говорити про петльові пристрої, я кажу лише про Linux, а не про Unix взагалі, оскільки петлеві пристрої не переносяться між системами типу Unix. У OS X, BSD тощо є подібні механізми, але синтаксис дещо відрізняється .
Ще в часи, коли дискові диски були розміром пральних машин і коштували дорожче, ніж розкішний автомобіль керівника відділу, великі комп'ютерні лабораторії поділяли б більшу частку їх колективного дискового простору порівняно з сучасними обчислювальними середовищами. Можливість прозорого прищеплення віддаленого диска до локальної файлової системи зробила такі розподілені системи набагато легшими у використанні. Тут ми і дістаємось/usr/share , наприклад.
Контрастна Windows, де віддалений диск, як правило, або відображається на букві диска, або має бути доступний через шлях UNC, а не прозоро інтегруватися в локальну файлову систему. Букви приводів пропонують вам декілька варіантів символічного вираження; робитьP: посилається на "загальнодоступний" простір на BigServer або на каталог "пакети" на дзеркальному сервері програмного забезпечення? Шляхи UNC означають, що вам потрібно запам'ятати, на якому сервері перебувають ваші віддалені файли, що у великій організації зі сотнями чи тисячами файлових серверів стає складним.
Windows не отримала посилань, поки Windows Vista, випущена в 2007 році, яка запровадила символічні посилання NTFS . Символічні посилання Windows трохи потужніші, ніж символічні посилання Unix - особливість Unix з 1977 року - в тому, що вони також можуть вказувати на віддалене спільне використання файлів, а не лише на локальний шлях. Unix зробив це по-іншому, через NFS в 1984 році , який будується на основі попередньо існуючої функції Unix, встановленої точкою кріплення , яку він мав з самого початку.
Тож, залежно від того, як ви на це дивитесь, Windows відстала від Unix приблизно за 2 або 3 десятиліття.
Навіть тоді символічні посилання не є звичайною частиною досвіду користувача Windows з кількох причин.
По-перше, їх можна створити лише за допомогою програми зворотного командного рядка MKLINK. Ви не можете створити їх за допомогою Провідника Windows, тоді як Unix-еквіваленти Windows Explorer, як правило , дозволяють створювати посилання.
По-друге, конфігурація Windows за замовчуванням перешкоджає звичайним користувачам створювати символічні посилання, вимагаючи або запустити командну оболонку як Адміністратор, або надати користувачеві дозвіл на створення їх через незрозумілий шлях в інструменті, який середній користувач ніколи навіть не бачив, тим більше знає як користуватись. (І на відміну від більшості проблем з правами адміністратора в Windows, UAC не допомагає в цьому випадку.)
У вікнах Linux не завжди використовується віртуальний диск у послідовності завантаження. Існує купа різних способів зробити це .
man ed
Дескриптори мережевих сокетів, між іншим, теж FD.