Board.KolibriOS.org

Лично я считаю, что существующее положение более удобно... Дело в том, что hd - имя устройства (hd1, hd2), а дальше идет номер (причем как я понимаю, порядковый) раздела. Виндовая организация конечно, более ущербна, но вот у линуха тоже не слишком удобно. Если только будешь именовать типа hd1p1, hd2p4, hdXpY - но это уже ИМХО, перебор. Вообще, с чисто логической организации здесь два уровня просится по-моему...

откройте кто-нибудь голосование, перенеся туда в один пост суть идеи. пожалуйста.

Сразу видно, что никто из здесь присутствующих не сталкивался с проблемой, которую я описал (изменение физического расположения винта с данными). Про Линукс вообще отдельный разговор, т.к., повторяю, там пространство имен устройств и пространство имен объектов ФС, через которые выполняется доступ к данным на этих устройствах на логическом уровне, вообще не пересекаются.

Смотри. В пределах одной машины ты часто винты и разделы перекидываешь? Нет, изменение разделов - максимум. Удаление и создание новых - раз в полгода - максимум. Тогда проблема решается просто - в _зависимости_ от _физического_ расположения раздела на носителе ему присваивается имя. Т.е. usb1/1 - первый раздел на USB-носителе, подключенном к первому usb-порту (тут мог иметь место некоторый ляп), hdi1/2 - второй по счету раздел примари_слейв жесткого ИДЕ диска. hds1/4 - четвертый раздел САТА диска. Причем это на физическом уровне. А вот в дополнение присваивать метки логическим томам - хорошее дело (например, ты как пользователь присваиваешь тому метку "программ файлс", а потом система интерпретируя метку тома всегда при изменении местоположения раздела обновляет пути согласно метке). Поэтому, считаю, что проблема решается разработкой и реализацией соответствующего алгоритма.

Хотите сказать /hd1/1/ удобней чем /hda1/? чем?

А если хочется прочитать данные напрямую с диска, на секторном уровне? Логичнее, чтобы LBA-чтение понимало и /hd1 (считывая данные физического диска), и /hd1/2 (считывая данные логического диска).

Погоди.
Я говорю про монтируемые имена!!!!! А не про прямой доступ к диску! Эт совсем разные вещи.
Прямой доступ это отдельная тема, и я ее трогать не собираюсь (возможно, т.к. не знаю как он сейчас в колибри устроен). А если и придется то тут спору нет, тут будет доступ и к диску и к его партициям и явно по физическим именам.

Почему же разные? Пути-то одинаковые... А если вводить две различные системы имён, это IMHO ненужное усложнение.

Вообще, я говорю именно про монтируемые имена. Чем удобнее hda1? Здесь все ясно: hd0/1 - жесткий диск0, раздел1. А hda1 - какой там у нас жесткий диск и раздел? интуитивно не понятно. Мне представляется, что это жесткий0, раздел1. А hda2 - это уже жесткий2, раздел1 или жесткий0, раздел2?

Hack_phoenix, так система не всегда сможет обновить пути, потому что они могут к примеру храниться в конфиг-файлах приложений. Да и потом на домашнем компьютере может быть я и не переставляю регулярно винты, но некоторым людям приходится этим заниматься постоянно, если не дома, то на работе.

С последними рассуждениями вообще не согласен. Более общий элемент обычно находится левее, чем частные - людям так привычнее, если конечны это не арабы, которые привыкли писать справа на лево.

diamond, в никсах две разные системы имен - это необходимость. Кстати, я тоже использую две разные системы, хотя структура ФС у меня не такая, как в никсах.

В общем, спорить можно до посинения. Каждый со своей стороны прав, у каждого свои аргументы.
Есть два пути решения вопроса:
1. Автору забить на мнение остальных. Как сказал Diamonnd, (и я с ним отчасти согласен) - у пишущего программиста превалирующая точка зрения.
2. Провести опрос. На результаты, которого все же можно забить, потому что см. п. 1. (Пустая трата времени, но рядовому представителю сообщества приятно, что его мнение по возможности учли)

пост Марио (+1)

Так вообще редко в какой системе есть та фишка, о которой я говорил, изначально. В некоторых системах этого можно добиться путем дополнительного конфигурирования. Схема с виртуальным корнем хороша именно тем, что ее при необходимости можно дополнить не в ущерб совместимости. Например, по аналогии с маками в корне файловой системы Колибри можно разместить каталог Volumes, внутри которого диски именовать не по их физическому размещению, а используя имена, хранящиеся на самих дисках. Правда, два разных пути попадания в одно и то же место многим могут не понравиться (мне, например, не нравится). К тому же у тех, кто использует защиту и на уровне ФС, могут возникнуть дополнительные проблемы.

Тема закрывается до первых результатов с чьей либо стороны.