Comments 76
Надо назвать диск русской Х и потом требовать разобраться, почему не видно в explorer
Диск С
Даже если какой-то файловый менеджер будет этот диск видеть, пользователь будет озадачен)
и зачем мне два диска цэ - удалюка я первый
Так это ж анекдот времён ранних нортоноподобных оболочек.
так так тааак.
слуушаем...
Оказывается, С и C - разные буквы. С одной программа работает, с другой нет.
«Один пользователь рассказывает наладчику:
Я включаю комп, а там с одной стороны диск C: и с другой - тоже диск C:. Ну, думаю, зачем мне два одинаковых диска C:. Я взял и один снёс».
Тема интересная, особенно если попробовать раскрутить в сторону скрытия каких-либо объектов от антивирусов и т.д. Вполне может быть, что какие-то вредоносы уже это используют.
Хотелось бы почитать аналогичную статью про имена файлов в NT (NTFS). Есть там ряд ограничений как по набору символов, так и по возможному расположению их (пробелы, точки в конце имени). И судя по всему, эти ограничения со временем менялись.
вредоносы прячутся внутри файловых систем
Особенно с усечением кодов символов. Вроде создания диска из system32 с экзотическим названием, которое усечется до C, а дальше вытягивать или писать данные как бы в другой диск. Интересный вектор атаки, но проверять мне лень :)
Зато поддерживаются Юниккодные управляющие символы. "Exexe.jpg" может на самом деле быть "Ex.jpg.exe" с символом чтения справа влево.
Просвещайтесь:
ДискЦ:/ - так можно?
Забавная статья. Только великовата.
Попробую пояснить, почему так сложилось. По поводу букв. В DOS было принято обозначение физических дисков латинскими буквами. A, B шли под флоппи диски, остальные уходили под появившиеся в ПК позже жесткие диски, ну и под зоопарк приводов для переносных хранилищ. С развитием Windows появилась возможность давать папкам псевдонимы в виде букв дисков. Проблема в том, что вот это обозначение дисков латиницей это вещь основополагающая, принята "по умолчанию". Разработчикам просто в голову не придет, что кто-то удосужится назвать диск спецсимволом. Косяк, да.
С развитием Windows появилась возможность давать папкам псевдонимы в виде букв дисков
В DOS 3.0 subst уже был, я им пользовался
Разработчикам просто в голову не придет, что кто-то удосужится назвать диск спецсимволом
В те годы 640 кБ хватало всем, поэтому экономили каждый байт, делая систему минимально достаточной и с разумным заделом на будущее. А теперь легаси как со стороны ОС, так и со стороны ПО не позволяют так радикально протащить спецсимволы или вообще юникод в имена дисков - до сих пор даже кириллицу в пути к файлу ещё не всё ПО допускает, поэтому и проблемы с такими именами дисков имхо тоже растянутся на десятилетия...
В те годы 640 кБ хватало всем, поэтому экономили каждый байт, делая систему минимально достаточной и с разумным заделом на будущее.
RT-11 работала на в десять раз меньшем объёме и при этом позволяла иметь имена дисков до трёх символов, вместо одного, как в CP/M с потомками типа MS-DOS. Поэтому во времена 640kB оправдания этому маразму уже не было.
Но MS-DOS 1.0 должна была работать на системе с 16kB. Вот там ещё можно было подумать...
Так как этот прикольный диск называется? +:\ или +: или + ?
Диск цэ, кстати, называется одной буквой, а не C:\
Мне кажется, в статье путают название и отображение.
Диск, конечно, имеет имя C, но запись C: используется, чтобы не писать "диск C".
(+:\ - это, разумеется, путь к корню диска +:.)
Даже нет. В первую очередь, C: - это консольная команда, переключающая текущий диск на диск C.
Интересно, как в эту парадигму грамматики путей уложить то, что и A:\AUTOEXEC.BAT, и A:AUTOEXEC.BAT указывают на один и тот же файл?
А это не одно и то же.
Грубо
./file vs /file
Не на один и тот же. A:\AUTOEXEC.BAT указывает на файл, находящийся в корне диска, а A:AUTOEXEC.BAT - на файл, находящийся в текущей папке на диске E:
Быстрая проверка в cmd.exe
Microsoft Windows [Version 10.0.19045.6456]
(c) Корпорация Майкрософт (Microsoft Corporation). Все права защищены.
e:\Download>test
passed.
e:\Download>d:
d:\Games>test
"test" не является внутренней или внешней
командой, исполняемой программой или пакетным файлом.
d:\Games>e:test
passed.
d:\Games>cd e:
e:\Download
d:\Games>cd e:\
d:\Games>cd e:
e:\
d:\Games>e:test
"e:test" не является внутренней или внешней
командой, исполняемой программой или пакетным файлом.
Б-р... Видя такие извращения меня сразу накрывают птср флешбэки, когда ловили ошибку суть которой была в том, что на вход нам прилетал "широкий пробел" вместо "пробел"😖
Интересно, Windows когда-нибудь отойдёт от концепции отдельных дисков, помеченных буквой? Мне кажется, структура Unix-like систем выглядит более современной.
А зачем сливать всё в кучу?
Когда раздел монтируется как директория, ему можно задать осмысленное имя, а не одну букву. Когда дисков много, это может быть удобно. Я, разумеется, не могу являться экспертом в этой области, не являясь разработчиком операционных систем, это скорее вкусовые предпочтения. У меня буквы дисков в Windows ассоциируются с временами дремучего MS-DOS с его многочисленными ограничениями.
Зачем монтировать диск в одно дерево и прятать где-то внутри структуры папок? Бред же.
Во-вторых, у людей обычно хватает памяти на 3-5 дисков. Вполне норм. А у кого памяти не хватает, можно воспользоваться командой, с которой началась статья.
С точки зрения Unix не бред, потому что все объекты операционной системы это файлы. Устройства в /dev, процессы в /proc, смонтированные разделы в /mnt, все просто и логично.
Но зачем это всё сливать в одно дерево? Не логичнее ли разделить его по разным логическим группам?
И назвать группы просто и понятно. C:, D:..
Зачем монтировать диск в одно дерево и прятать где-то внутри структуры папок?
Потому что важней структура папок, а не то, на каком физическом носителе они расположены. Это позволяет размещать данные на разных носителях не меняя способов доступа к ним (адресации).
Но зачем это всё сливать в одно дерево? Не логичнее ли разделить его по разным логическим группам?
А зачем логику привязывать к букве? Разве в букве диска есть какой-то логический смысл? Это же просто способ адресации, как папка.
В Unix всё и так отлично поделено на логические группы не зависимо от физического расположения: /dev, /run, /root, /etc, /var, /tmp, /home и т.д. В каждой папке определённый тип объектов.
Физическое расположение важно. В Windows часто ставят программы не в системный каталог, а на отдельный диск (на системном часто заканчивается место). Диски в системе могут быть зашифрованы, и тогда после загрузки системы часть каталогов будет доступна, а часть нет (пока не введёшь пароль). Плюс сами диски могут ломаться и сыпаться, и хочется явно определить на них данные, которые мы готовы или не готовы потерять.
Ага, и все ссылки на эти данные становятся зависимы от буквы этого диска.
Вы описываете важность для пользователя. А я про важность для системы.
С точками монтирования точно также, только удобнее ;) Не D: , а /mnt/games. Windows, кстати, тоже умеет в точки монтирования.
В Windows часто ставят программы не в системный каталог, а на отдельный диск (на системном часто заканчивается место).
В Unix тоже.
Диски в системе могут быть зашифрованы, и тогда после загрузки системы часть каталогов будет доступна, а часть нет (пока не введёшь пароль).
Точно так же, с учётом поддеревьев.
Плюс сами диски могут ломаться и сыпаться, и хочется явно определить на них данные, которые мы готовы или не готовы потерять.
Если хочется залезть в эти детали - mount даёт список текущих монтирований. В случае LVM соответственно рассматривается, что входит в volume group.
Зачем монтировать диск в одно дерево и прятать где-то внутри структуры папок? Бред же.
Бред или нет, а в Windows это сделали, причём ещё менее понятно, по ссылке описано. Одна иерархия, в которой \\?\ задаёт, что дальше будет файл из файловой системы, а за пределами этого поддерева разные спецобъекты.
Но это сделали внутри, может это удобнее разработчикам ОС. Это не сделали для юзеров, которым удобнее ощущать чёткое разделение где у них что лежит.
Я бы насчёт этого "удобнее" слегка поспорил. Во-первых, удобнее разделять постоянные и временные носители, поэтому в современных линуксах подкаталоги для вторых создаются в /media/$user/, а графические средства типа Dolphin или Windows Explorer это всё равно обобщают. Во-вторых, c динамическими дисками под LDM это уже становится заметно менее важным. В-третьих, как-то не очень смысла спамить общее пространство намонтированными структурами типа того, что в Ubuntu заводятся для каждого снапа...
Если бы вместо букв и/или имён дисков была своя иерархия, которая бы позволяла делать что-то вроде /disk/root:/windows/explorer.exe с небольшим количеством алиасов типа root вместо /disk/root, то я бы вполне согласился.
Мне, если честно, концепция букв нравится больше, чем сваливание всего в одну структуру. Ну, ситуации конечно разные бывают, и иногда удобнее монтировать сетевую папку в другую папку. Но для домашнего или мелко-офисного использования удобнее отдельные буквы на каждое устройство
Это должны быть не буквы, а имена произвольной длины (хотя бы до 8 символов).
Самое смешное, что изначально такие имена устройств поддерживались, всякие там CON: и LPT2:
Не-а, там другой механизм. Они не в том же пространстве, что имена дисков, а как бы встроены в любой каталог, причём с любым суффиксом, что само по себе диверсия. В RSX-11 с компанией они логично размещались, например, copy dk0:foo.txt lp0: (не помню точного названия для принтера) давало, что драйверу принтера уходило имя файла (внутри второй аргумент превращался в lp0:foo.txt), он мог выбрать от этого режим печати, нарисовать заголовки и так далее...
И не "поддерживались", а поддерживаются и сейчас, если путь не изначально передан в WinAPI как UNC.
Do not use the following reserved names for the name of a file:
CON, PRN, AUX, NUL, COM1, COM2, COM3, COM4, COM5, COM6, COM7, COM8, COM9, COM¹, COM², COM³, LPT1, LPT2, LPT3, LPT4, LPT5, LPT6, LPT7, LPT8, LPT9, LPT¹, LPT², and LPT³. Also avoid these names followed immediately by an extension; for example, NUL.txt and NUL.tar.gz are both equivalent to NUL. For more information, see Namespaces.
Как вам устройство COM¹, неявно присутствующее в любом каталоге? 😱
В UNC режиме (префикс \\?\) этот разбор на такие имена выключается, вместе со многими другими (нельзя /, только \; нельзя относительные пути, только абсолютные).
Согласен. Понятно, что где лежит и какие файлы на каком диске. Это и безопаснее с точки зрения сохранности данных, чтобы не гадать, условно какой диск посыпался и на каком из носителей лежит n-ный файл.
Для домашнего использования буквы гораздо удобнее и практичнее. Для каких-нибудь серверов - да, могут быть удобнее unix-подобные fs и обозначения, ибо там нередко много дисков, обозначать которые может быть удобнее определённой последовательностью символов - имя+номер или тп.
Это и безопаснее с точки зрения сохранности данных, чтобы не гадать, условно какой диск посыпался и на каком из носителей лежит n-ный файл.
Достаточно бесполезное знание. Если физический диск 1 - и так все очевидно. Если raid - наоборот. Пережиток тех времен, когда система на диске С а игры на диске Д
чтобы не гадать, условно какой диск посыпался и на каком из носителей лежит n-ный файл.
Гадать не надо. Команда mount расскажет всё что надо.
Исходно эта схема с одной буквой получена упрощением той, что была в операционных системах RSX-11 и родственных, где название диска могло содержать до 3 символов не считая двоеточия, например, DK0:, SY:, и алиасы были штатным свойством (SY был алиасом на системный диск). Когда делалась CP/M, уплощили до одной. Потом не вернули обратно всё время жизни DOS и Windows. Вот это действительно неудобно, букв слишком мало и в них слишком легко получить конфликты.
Unix система хороша, но не напрямую одной иерархией: внутри она совершенно не обязательно одна. С современными средствами можно, например, запустить процесс, у которого корнем будет /opt/foo хозяйской системы, а /var/db/foo будет доступен через отдельный дескриптор, и все доступы надо будет делать относительно него через *at() вызовы, как openat(), mkdirat() и тому подобные. В Windows так не работало бы: Windows внутри всегда требует полного пути и итерирует от общего корня.
где название диска могло содержать до 3 символов не считая двоеточия, например, DK0:, SY:, и алиасы были штатным свойством (SY был алиасом на системный диск). Когда делалась CP/M, уплощили до одной. Потом не вернули обратно всё время жизни DOS и Windows.
Ну не совсем так. Название диска включала в себя драйвер и потом уже номер диска. DX[0,1...] это восьмидюймовые дискеты, MX, MY - пятидюймовые.
UNC же есть
Это всё легаси. Если очень надо, через диспетчер дисков можно задать диску точку монтирования в виде выбранной папки. (Можно даже несколько.)
Смонтировать диск в папку и в Windows можно:
В управлении дисками для раздела можно назначить как букву, так и путь к папке.
Вот пример на картинке для DVD привода попробовал назначить путь, а букву диска вообще убрал, теперь содержимое диска доступно по пути "/CD".
Цифры можно использовать?
Во времена DOS имя диска любой символ диапазона 0x40...0x5F (&, A-Z, [, \, ], ^, _). Диск &: не рекомендовался к использованию. Диски [:, ]: создавались и обрабатывались без проблем.
explorer.exe в эти игры не играет
Расходимся, нас обманули )
После того, как накрылся SSD с операционной системой (Windws 10), некоторое время пришлось работать на ноутбуке с внешнего HDD.
На внешнем HDD, унутри, в коробочке, находился старый HDD,вынутый из ноутбука"HP".
На ём осталась "родная" операционная система (Windws 10).
Воткнёшь внешний диск (с Windws 10)в USB-порт, ноутбук и работает.
Позже, эта "родная" операционка была установлена на SSD(512 Gb),установленный внутри ноутбука.
Чтобы обезопасить себя в дальнейшем от подобного варианта сбоя, я скопировал на другой внешний SSD (256 Gb), эту "родную" операционную систему.
Но после этого, при каждом подключении внешних дисков (HDD или SSD), операционная система стала требовать "букву"(на латинице), подключаемого внешнего диска.
И каждый раз, приходилось назначать новую "букву", новому внешнему диску.
Сейчас у меня обозначены таким образом уже 16 внешних дисков.
Когда кончатся все "буквы", предлагаемые ОС Windws 10, как именовать следующие внешние диски?
В английском алфавите всего 26 букв.
А цифры совместно с "буквами", операционка не предлагает.
В качестве букв диска в Windows может использоваться не только латиница