Тед Цо (Ted Ts'o), автор файловых систем ext2/ext3/ext4, принял (https://lists.openwall.net/linux-ext4/2019/04/25/23) в ветку Linux-next, на основе которой будет сформирован выпуск ядра Linux 5.2, набор изменений (https://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.g...), реализующих поддержку регистронезависимых операций в файловой системе Ext4. Патчи также добавляют поддержку символов UTF-8 в именах файлов.
Режим работы без различия регистра символов может включаться в привязке к отдельным каталогам при помощи нового атрибута "+F" (EXT4_CASEFOLD_FL). При установке данного атрибута на каталог все операции с файлами и подкаталогами внутри будут производиться без учёта регистра символов, в том числе регистр будет игнорироваться при операциях поиска и открытия файлов (например, файлы Test.txt, test.txt и test.TXT в подобных каталогах будут считаться одинаковыми). Для управления включением регистронезависимого режима предлагается модифицированный набор утилит e2fsprogs (https://gitlab.collabora.com/krisman/e2fsprogs).Патчи подготовлены Gabriel Krisman Bertazi, сотрудником компании Collabora, и приняты с седьмой (https://lists.openwall.net/linux-ext4/2019/04/13/10) попытки после трёх лет (https://lists.openwall.net/linux-ext4/2016/11/03/5) разработки и устранения замечаний. Реализация не вносит изменения в дисковый формат хранения и работает исключительно на уровне изменения логики сравнения имён в функции ext4_lookup() и замене хэша в структуре dcache. Значение атрибута "+F" сохраняется внутри inode отдельных каталогов и распространяется на все вложенные файлы и подкаталоги. Информация о кодировке сохраняется в суперблоке.
Для того чтобы избежать коллизий с именами существующих файлов атрибут "+F" может быть установлен только на пустые каталоги в файловых системах, в которых на этапе монтирования включён режим поддержки Unicode в именах файлов и каталогов. Имена элементов каталогов для которых активирован атрибут "+F" автоматически переводятся в нижний регистр и сохраняются в таком виде в dcache, но на диске сохраняются в изначально заданном пользователем виде, т.е. несмотря на обработку имён независимо от регистра, имена показываются и сохраняются без потери информации о регистре символов.
URL: https://lists.openwall.net/linux-ext4/2019/04/25/23
Новость: https://www.opennet.me/opennews/art.shtml?num=50581
Виндовенько.
На удивление, и на винде есть логичные вещи
Отключение регистра зависимости?
И включение его Linux с лоббированием через купленный GitHub чтобы его еще и принудительного включали пол предлогом совместимости. А то ведь Windows ведь такой совместрмый... со всеми виндоусами, какие только были!А почему это Linux с виндоусами не совместим? Не порядок!
Да это вполне логичный ход... с точки зрения пользователей Windows, на мышление которых сам Windows чисто случайно рассчитан. Совместимость прежде всего! И не важно с чем. Ждите теперь на Гитхабе код теперь уже еще и под Linux, "рассчитанный" на эту, так сказать, "совместимость".
Если вы про сабж, то тогда в DOS-е. Ведь эти костыли растут оттуда.
А в досе из СР/М, а в СР/М из TOPS-10.
Разумеется есть, если не вестись на пингвинячьи песни.Я их уже двадцать лет слушаю:
Винда пишется продажной корпорацией, а Линукс разрабатывается свободным сообществом! - В итоге, 80% вклада в ядро вносят продажные корпорации.
У Винды код закрытый и написан индусами, а Линукс разрабатывают профессионалы которые знают своё дело! - Алан Кокс отстраняется от разработки Линукса, после попытки переписать говнокод tty не сломав при этом юзерспейс.
Винда - говно, в ней все приложения жирные и напичканные ненужным функционалом! - Но сами переходят с лёгкого lilo на жирный GRUB, с встроенным веб-браузером.
В Винде все настройки и логи - бинарные, если что-то сломается то без специальных утилит не посмотришь, а у нас в Линуксе всё хранится текстом и полно утилит для его парсинга! - Но, в конце-концов, все основные дистрибутивы перешли на поделки Поттеринга с бинарными логами и бинарными настройками.
Как ты там в Винде? Все диски дефрагментировал? - Впопыхах, пишут дефрагментатор для ext4.
У нас, в Линуксе, каждая подсистема state-of-the-art. Взять хотя бы иксы, которые могут передавать изображение с экрана через сеть! - Отказываются от иксов в пользу Wayland и Mir - без сетевой функциональности, зато в разы быстрее.
Я бы тебе не плюс, а что-то больше поставил. Всё в точку попал.
> Винда пишется продажной корпорацией, а Линукс разрабатывается свободным сообществом! - В итоге, 80% вклада в ядро вносят продажные корпорации.На это плевать всем, кроме отдельных фанатиков. Опять же, с продажных корпораций хоть шерсти клок.
> Алан Кокс отстраняется от разработки Линукса, после попытки переписать говнокод tty не сломав при этом юзерспейс.
То-то каждый месяц уже предупреждения выходят про виндовые обновления - "kbNNNNNNN не ставь, оно ломает то-то".
> Винда - говно, в ней все приложения жирные и напичканные ненужным функционалом!
Винда "из коробки" пользовательского ПО почти не содержит, и весит при этом установленная больше, чем несчастный пингвин с установленным ПО.
> Но сами переходят с лёгкого lilo на жирный GRUB, с встроенным веб-браузером.
Внезапно, lilo и extlinux/syslinux никуда (как минимум из дебиана и производных) не выкинуты, не хошь grub, ставь их.
> В Винде все настройки и логи - бинарные, если что-то сломается то без специальных утилит не посмотришь,
Более того, записи, относящиеся к конкретному приложению, после сноса приложения превращаются в тыкву, т.к. требуют .dll со строковыми значениями в ресурсах. Кроме того, у типового виндового приложения, писанного непродажной корпорацией, логи вообще писать не принято, а подсистемы самой винды, кроме тех "бинарных логов" нередко пишут еще и текстовые - каждый в своём формате и непременно в каком-нибудь малоочевидном месте. Могу примеры привести, если интересно.
> а у нас в Линуксе всё хранится текстом и полно утилит для его парсинга! - Но, в конце-концов, все основные дистрибутивы перешли на поделки Поттеринга с бинарными логами и бинарными настройками.
И при этом по journald (как минимум в том же дебиане и производных) по умолчанию настроен так, что свои журналы на диске не хранит, и дублируется тёплым ламповым rsyslog'ом (который таки пишет текстовые файлы).
> Взять хотя бы иксы, которые могут передавать изображение с экрана через сеть! - Отказываются от иксов в пользу Wayland и Mir - без сетевой функциональности, зато в разы быстрее.
Mir умер вместе с Unity (и туда ему и дорога). Wayland пока еще допилят... а всеми изруганные "архаичные" иксы живее всех живых и молча работают. Передача через сеть на типовом ПК нужна крайне редко, и опять же в случае клиент-серверного приложения как-то более актуальны либо веб-морды, не привязанные к конкретной ОС, либо "толстые клиенты" в случае чего-то тяжёлого и специфического.
В общем, наброс ваш не удался.
Да фигня обе ОС, толи дело старый добрый DOS... Все просто и понятнео без кучи наворотов лишних.
Однакл приходится выбирать из того что есть, и для разных задач то линукс лучше заедет то винда... Бубен в любом случае под столом лежать должен.
> Разумеется есть, если не вестись на пингвинячьи песни.Ты сам-то понял, где наврал?
>> Разумеется есть, если не вестись на пингвинячьи песни.
> Ты сам-то понял, где наврал?"" Понгвин - птица певчая. Пока не пнёшь не запоёт. ""
>Винда пишется продажной корпорацией, а Линукс разрабатывается свободным сообществом! - В итоге, >80% вклада в ядро вносят продажные корпорации.А продажные компании используют СПО в хвост и гриву. Помоему все по честному.
Слишком толсто, да и опоздало лет на -надцать. Давно уже пора вырасти из холиваров и пользоваться тем, что оптимально подходит под задачу. Хотя если больше делать нечего, то холиварьте, конечно.Кто в реале плотно работал с разными ОС, тот отчётливо знает, что всё это те же яйца, вид сбоку.
> Слишком толсто, да и опоздало лет на -надцать.Не, не опоздало. Почитай ответы к этому вбросу, и ты поймёшь, что он всё ещё актуален.
Я орнул когда они сперва захейтили маковский launchd и его подход к инициализации сервисов(по запросу) после чего в системд по тихому спустя годы была запилена похожая возможность.
Да многое так было с маком. Поносили dmg - напилили снап и Флатпак.
Толсто.
Таки NTFS поддерживает регистрозависимость, просто она выключена для совместимости.
Где включить?
fsutil.exe file setCaseSensitiveInfo "Путь до папки" enable
А соответствующий ключик реестра в 7-ке есть?
Да, есть. Начиная с Win2000, есть возможность включить регистрозависимость.
Использовать Native API вместо Win32 API и обёрток над последним.
Это, конечно, так ускорит винду...
ты шаришь в винде ?
подскажи где в реестре 10-ки
можно увеличить уровень звука - очень слабый на ноуте
на форумах виндовых одни имбицильные стремы а толкового ответа нет
у меня так было, заменил дрова от производителя чипа дровами с сайта производителя ноутбука.
>Виндовенько.Так для виндопримочек, скорее всего, и делается: samba, wine, dosbox до кучи.
Можно использовать для почтового сервера, например. user+dir@mail.com и user+Dir@mail.com будут складываться в одну директорию...
Можно обыграть на уровне приложения
нет разницы где ставить костыли
Разница есть. Вот вы почту получаете. Казалось бы, причем тут ФС
а ключики на что? %L дает счастье>Dovecot:
>mail_location = maildir:/usr/local/virtual/%Ld/%Ln
>>Виндовенько.
> Так для виндопримочек, скорее всего, и делается: samba, wine, dosbox до кучи.Не! У них на в*нде git тормозит. Вот смотри: как только запилят регистронезависимость в git -- знач усё, Они переходят на "новое" ядро. >X<<<<P>
DOSасто же
Наконец-то пофиксили
Будет теперь как у взрослых (MacOS например).
В HFS+ наоборот вроде было — включать требовалось как раз чувствительность к регистру.
HFS и HFS+ уже легаси, все новые установки идут на APFS
Ну да взрослая уже память ни к чему вот по этому бывает что теряет часть данных.
https://www.cio.com/article/2868393/linus-torvalds-apples-hf...
И зачем? Даже в NTFS уже поддержку чувствительности к регистру завезли.
Дык из Ext4 у тебя её никто и не забирает.
В NTFS изначально чувствительна к регистру, в отличие от Windows.
> В NTFS изначально чувствительна к регистру, в отличие от Windows.Она ещё и к 8.3 "чувствительна", да? Нужная фича -- вон тут половина населения "пользуется каждый день".
Отбейте телеграмку в LKML.
А всего-то 4 года назад Линус, отчасти из-за нечувствительности к регистру, поливал макосёвую HFS+ помоями, и называл разрабов Apple обезьянами.
И правильно делал
Это он ещё apfs не видел.
На hfs+и apfs оно настраивается. А такой дефолт из-за ошибок молодости, теперь это уже не исправить не сломав кучу софта.
>А такой дефолт из-за ошибок молодости, теперь
> это уже не исправить не сломав кучу софта.Ога. Теперь пусть Тед _нам_ всё поломает.
Будем подпрыгивать -- "как молодые"[I]!
да никто ж не предлагает это дерьмо включать без крайней необходимости, типа файлопомойки с 100% виндовыми клиентами
> да никто ж не предлагает это дерьмо включать без крайней необходимости, типа
> файлопомойки с 100% виндовыми клиентамиТы уверен, что Тэд со казачки-товарищи не сломал и мой "включённый" код?
И не сломает его в следующий раз, когда будет чинить этот завезённый опечатанными вагонами блоат?
И в следующий?...
И когда будет обновлять для "поддержки" каки-лошади-кошечки емодзи для уникода N+1?
И опять "не затронет" мой, включённый код?
Как проверял?
А где в статье написано, что эту возможность Линус добавил?
...а ещё лет через 20 они догадаются, что 255 байт (именно байт, а не символов Unicode) на имя файла - это как-то совсем уж мало.
А на кой черт больше то? o_O
Даже при 2-х байтах это 127 символов. Правда какой-нибудь SHA-512 уже не влезет, но его можно через base64 прогнать и тогда влезет.
>А на кой черт больше то? o_OНе знаю, как сейчас дела обстоят, а раньше названия всякой фигни с русских торрент-трекеров внушали: лимит байтов для ext4 дятлы-варезники превышали раза в полтора легко.
Разработчики, ограничившие длину имени 255 байтами, конечно же не тормозные дятлы
> Разработчики, ограничившие длину имени 255 байтами, конечно же не тормозные дятлыНет. Я, как и они, тоже не понимаю, на кой нужны сверхдлинные имена файлов.
Я вообще ни разу не видел, чтобы кто-то кроме вышеуказанной категории использовал настолько длинные названия — это ж неудобно, даже в файловом менеджере сверхдлинные названия просматривать — уже как-то не особо хорошо.
И ещё не понимаю, почему 255 байт это караул, а 255 символов — норма.
> это ж неудобнопросто у вас нет трёх fullhd мониторов по горизонтали, вот вы и завидуете. а у кого-то есть. вместе с достаточным запасам веществ, расширяющих не только сознание, но и угол обзора.
> просто у вас нет трёх fullhd мониторов по горизонтали, вот вы и
> завидуете.На работе как раз 3x fullhd и ещё проектор время от времени подключать приходится.
Дома fullhd + старенький 1280x1024 для вывода видеозвонков и крепления вэбки, благо толщина позволяет. Всё равно не понимаю.
> трёх fullhd мониторов по горизонталиТаноквый триплекс как он есть. Это прямо дно подвала с картошкой.
>Я вообще ни разу не видел, чтобы кто-то кроме вышеуказанной категории использовал настолько длинные названия — это ж неудобно...Мне не нужно — значит никому не нужно (лозунг всех линуксоидов). А потом нытьё про 2%.
>Я, как и они, тоже не понимаю...
«... и не пытаюсь понять» — логичное продолжение мысли.
> Мне не нужно — значит никому не нужно (лозунг всех линуксоидов). А
> потом нытьё про 2%.Вообще-то это лозунг виндоюзеров, что до 2% — так тут ещё вопрос, хорошо это или плохо. 10+ % ценой заточки софта под вендотолпу мне лично не нужны.
> мне лично не нужны.Да ты и сам не нужен большинству, со своим «ценным» мнением. Людям, которые двигают вперёд линукс и вкладывают в него бабки твоя идеология и мысли в принципе не нужны.
> Да ты и сам не нужен большинству, со своим «ценным» мнением.Какому такому большинству? Кто такие? Поименно.
> которые двигают вперёд линукс
В этом вопросе важно не только направление, но и что на этом направление находится. А там может находиться могила, к примеру.
>и вкладывают в него бабки
Немало хороших вещей сгинуло как раз по причине того, что в них «вкладывали бабки».
>Нет интегрированного в клиенты механизма обмена медиафайлами.
Истерика?
>Немало хороших вещей сгинуло как раз по причине того, что в них «вкладывали бабки».Каких таких хороший вещей? Что за вещи? Поимённо.
> Каких таких хороший вещей? Что за вещи? Поимённо.Легко.
Mozilla Firefox.
Компьютерный игрострой.
Американский кинематограф.Что-то не целиком и не полностью, но близко к тому.
Что поделать: «вкладывают бабки» обычно чтобы их приумножить или хотя бы не потерять. Потому «вложенные бабки» и их хозяева не терпят никаких рисков и творчества, старательно гробя «облагодетельствованный» продукт или направление.
> Mozilla Firefox.Отличный браузер, с годами стал лучше. Пользуюсь, пожалуй, с первых версий ± пару лет.
> Компьютерный игрострой.
Количество хороших игр, которые выходят каждый год превышает количество игр выпущенных вообще 20 лет назад. О чём ты?
> Американский кинематограф.
Тут вообще без комментариев. Шедевральность кинофильма никак вообще не коррелирует с его бюджетом. А диванные кинокритики забывают к тому же учитывать ЦА фильмов, жанр (и его неизбежные ограничения) и цели авторов данного конкретного кино, критикуя в итоге условных «Трансформеров» за недостаточную проработанность и драматичность любовной линии ГГ.
Есть подозрение, что ты мил человек балабол, изъясняющийся штампованными фразами и чужими мыслями.
> Отличный браузер, с годами стал лучше. Пользуюсь, пожалуй, с первых версий ±
> пару лет.Только вот нерабочий.
> Количество хороших игр, которые выходят каждый год превышает количество игр выпущенных
> вообще 20 лет назад. О чём ты?О том, что нет, не превосходит.
>Шедевральность кинофильма никак вообще не коррелирует с его
> бюджетом.Коррелирует.
>цели авторов данного конкретного кино,
Срубить бабла. В этом-то и проблема.
> Есть подозрение, что ты мил человек балабол, изъясняющийся штампованными фразами и чужими
> мыслями.Есть твёрдая уверенность, что ты — тупое хамло.
> Какому такому большинству? Кто такие? Поименно.Все миллиарды людей, которые знать не знают кто ты такой? Ищи сам.
> В этом вопросе важно не только направление, но и что на этом направление находится. А там может находиться могила, к примеру.
Ну так двигай сам. За свои бабки. И за них двигай свои идеи. Тебе лично никто ничего не должен.
> Немало хороших вещей сгинуло как раз по причине того, что в них «вкладывали бабки».
И, заметь, никакое «сообщество», которое, по мысли человека-стола, могло бы поддержать эти открытые проекты, ничего не сделало. Это ещё раз говорит о том что «сообщество» — это пустые балаболы.
> Истерика?
Хз, спрашивай у того, кто это сказал.
> Все миллиарды людей, которые знать не знают кто ты такой? Ищи сам.Тебя-то эти мифические миллиарды тоже не знают, однако ж у тебя хватает наглости говорить от их имени. Иди сам. Адрес знаешь.
>никакое «сообщество», которое, по мысли человека-стола, могло бы
> поддержать эти открытые проекты, ничего не сделало.Когда бы вверх могла поднять ты рыло…
> И ещё не понимаю, почему 255 байт это караул, а 255 символов — норма.Не караул. В Windows и macOS больше. Поэтому это всё же проблема не галактическая, но проблемка.
Времена меняются.
В Emoji например есть последовательности, типа 🌈+ 🏳= 🏳️🌈
И их много, могут быть большими
https://www.unicode.org/reports/tr51/#SkinTonesForGroupingsU...
> В Emoji например есть последовательности, типаДолго не мог уяснить, кто этим пользуется. Теперь представляю предельно чётко.
А зачем нужны emoji в именах файлов/каталогов? Какие эмоции должны передавать названия объектов ФС?
> А зачем нужны emoji в именах файлов/каталогов? Какие эмоции должны передавать названия
> объектов ФС?Эмоции, судя по примеру, могут быть разные. От "вау, отправь плиз мне этот няшный видосик" до "фу такое смотреть".
> Эмоции, судя по примеру, могут быть разные. От "вау, отправь плиз мне этот няшный видосик" до "фу такое смотреть".Предлагаю держать таких людей как можно дальше от компьютеров и интернета.
Вы путаете эмоции с графикой.
А возможность задать имя файла "борьба женщин в грязи" одним символом это внушает. :)
> В Emoji например есть последовательности, типа 🌈+ 🏳= 🏳️🌈Посмотрел ссылку. Символы для девушек, держащихся за руку, «мужчин» держащихся за руку, две бабы с задницей (называемой другими сердцем) между ними...
Гомолобби в юникоде. давно пора создать кодировку без всего этого мусора.
Вампир-негр. Кому это нужно. Рожицы изначально были нейтральны к полу, расе и национальности, а теперь это рассадник всяких фобий. Одни для негров, а другие для белых. Расизм.Но ты, коняшка, не переживай, скоро и для зоофилов нарисуют символы, и ты сможешь отправлять своим друзьям смайлик, где ты сношаешь единорога, или он тебя.
Ну разумеется. Если чего-то нет в Линуксе, то это и не нужно. А то что у азиатов каждый символ весит по три байта и поэтому длина имени файла упирается в 85 символов, то это ничего - 255 байтов хватит всем.
> у азиатов каждый символ весит по три байта и поэтому длина имени файла упирается в 85 символов85 иероглифов — это небольшой рассказ накатать можно. А в слоговой письменности вполне соизмеримо с двухбайтной кириллицей. Ergo: раз мне хватает выше крыши, значит и им должно хватать.
> Ну разумеется. Если чего-то нет в Линуксе, то это и не нужно.
> А то что у азиатов каждый символ весит по три байта и поэтому длина имени файла упирается в 85 символов, то это ничего - 255 байтов хватит всем.Хм, если это так мешает азиатам, то почему еще нет патчей/форков?
>даже в файловом менеджереАдмины локалхостов с LA 0.0 не палятся. Ограничения на длину имени файла не нужны. Впрочем, ext* тоже не нужны, ни с +F, ни без него.
При виде подобного меня безудержно тянет блевать. Данная система защиты безальтернативно приводит к отказу от закачки.
> При виде подобного меня безудержно тянет блевать. Данная система защиты безальтернативно
> приводит к отказу от закачки.Многие торрент-клиенты умеют это дело как-то переименовывать (но это лучше уточнить, т. к. могу и напутать, как именно они проблему решают). Так что при соответствующем клиенте о данной проблеме можно и не узнать. Вот у transmission в багтрекере такая проблема точно была. Я, собственно, две проблемы transmission помню: вот это вот и регулярное затроянивание/забэкдоривание версии для MacOS.
Ну например мне по работе нужно было.
В 1С у объектов в конфигурации иногда могут быть длинные названия, больше чем 127 символов кириллицей.1С при разборке конфигурации выгружает каждый из них в отдельный файл с именем как у объекта и эти файлы создать не может на ext4.
Мне из-за этого приходилось выгружать на ntfs (sic!) смонтированном через ntfs-3g, так как все линуксовые фс (которые были в дистрибутивном ядре) имели такое же ограничение.
В reiserfs 4k лимит вроде был.
Самая-то радость в том, что ограничение в 255 байт - не в ФС, а в ядре, ЕМНИМС.
Багрепорт в 1С отправил?
> Багрепорт в 1С отправил?Багрепорт об ограничении линуксовых фс? Нет, они и так об этом в курсе и при выгрузке предупреждают что такие-то такие-то объекты не будут выгружены из-за слишком длинного имени.
> Даже при 2-х байтах это 127 символов.Напоминаю, что в utf-8 на один символ может быть до 4х байт, т.к. стараниями юникодного комитета в кодировке уже 1112114 символа...
А длинное имя может быть вида "Хрюкин А.В., Кабанченко У.П., Методы и приёмы работ при свежевании летающих слонопотамов в верхних слоях атмосферы с использованием углекислотных лазеров (М., 1989)", например - уже 164 символов, 293 байта.
> Напоминаю, что в utf-8 на один символ может быть до 4х байт,
> т.к. стараниями юникодного комитета в кодировке уже 1112114 символа...
> А длинное имя может быть вида "Хрюкин А.В., Кабанченко У.П., Методы и
> приёмы работ при свежевании летающих слонопотамов в верхних слоях атмосферы с
> использованием углекислотных лазеров (М., 1989)", например - уже 164 символов, 293
> байта.Отличный пример: ФС пытаются заставить выполнять несвойственную ей функцию базы данных, при этом слив все поля в одно. При этом о сколь-нибудь удобном обращении с файлами и каталогами с подобными названиями речи не идёт.
Т.е. пользователь для ПО, а не ПО для пользователя?
А удобство - вещь субъективная. Кому-то дерево каталогов вида "документация/инструкции/производственные/вот эта хрень про слонопотамов" более чем удобно. Особенно если это лежит на личном ноутбуке с нерегулярным доступом к сети. И упомянутый "кто-то" в командировке на объекте, находящемся в какой-нибудь тундре, и интернет на объекте если и есть, то медленный, дорогой, и для владельца объекта, а не для командированных из сторонних организаций.
>Особенно если это лежит на личном ноутбуке с нерегулярным доступом к сети. И упомянутый "кто-то" в командировке на объекте, находящемся в какой-нибудь тундре, и интернет на объекте если и есть, то медленный, дорогой, и для владельца объекта, а не для командированных из сторонних организаций.А что, в тундре файловые операции происходят не так, как в той же лесостепи, к примеру?
ФС это самая первая база данных.
Тогда пользуйся ей как базой данных:Хрюкин/1989
Кабанченко/1989 -> ../Хрюкин/1989
> Тогда пользуйся ей как базой данных:
> Хрюкин/1989
> Кабанченко/1989 -> ../Хрюкин/1989достаточно:
статьяДля всего остального вообще-то давно придумали расширенные атрибуты.
Еще бы их поддерживали не на "от#бись", вообще бы хорошо было, но подозреваю, для этого нужно их достаточно массовое использование, которого не будет без достаточного удобства/поддержки и ухода от "мы давно привыкли запихивать все в имя файла, нам все норм" 🙄
Расширенные атрибуты — ещё более ненужный костыль, чем сабж.
> Расширенные атрибуты — ещё более ненужный костыль, чем сабж.Аноним№1 прав, потому не нужен твой комментарий.
> Расширенные атрибуты — ещё более ненужный костыль, чем сабж.Костыль, это по-моему как раз попытка замапить все подряд на древовидную структуру ФС.
Например, я пользуюсь Calibre в качесте БД для книг и статей.
На ФС там оно мапится вот так:
~/Calibre Library
Ben\ Klemens
│ └── 21st\ Century\ C_\ C\ Tips\ From\ the\ New\ School\ (234)
│ ├── 21st\ Century\ C_\ C\ Tips\ From\ the\ New\ School\ -\ Ben\ Klemens.pdf
│ ├── cover.jpg
│ └── metadata.opf
├── Bjarne\ Stroustrup
│ └── The\ C__\ Programming\ Language\ (19)
│ ├── The\ C__\ Programming\ Language\ -\ Bjarne\ Stroustrup.pdf
│ ├── cover.jpg
│ └── metadata.opf
"Удоообноо" (c) - если бы пришлось навигировать только по ФС.При этом не отображаются тэги, дата публикации, издательство и рейтинг с комментариями.
Как и к
Хрюкин/1989
Кабанченко/1989 -> ../Хрюкин/1989
желательно еще название, теги, комментарий и прочее.
И автоматика, которая будет добавлять или убирать после удаления статьи/книги, дабы не оставлять кучи непонятных артефактов.
Но нет, использование xattr, на которые такой юзкейз хорошо ложится конечно же костыль,
а вот создавать кучу иерархий с симлинками (а на деле - пихать все в имя файла) -- отличное решение 🙄
Имя файла, пардоньте, при копировании по сети и/или на другую ФС не уродуется (при условии, что на принимающей стороне нет проблем с кодировками и длиной имени файла). А метаданные как в общем случае передавать? Вон, в NTFS альтернативные потоки данных есть - хошь метаданные пихай, хошь еще чего. И кто этим кроме самой винды и _вроде бы_ кацпердского пользуется? У однокнопочных тоже вон какие-то атрибуты в ФС есть - при копировании на не-маковскую ФС добавляют скрытый каталог с теми метаданными. И много с них толку в винде или линукс?
Ну, можно очередной "универсальный" формат для метаданных придумать, не привязанный к ФС.
Sidecar-файл в формате xml, как у Adobe.
Вот тупо будет пара файлов - filename.ext и filename.ext.metadata.
И кто этим пользоваться будет, даже если какая-то контора масштаба межделмаша международный стандарт продавит? А никто.
Потому "пихать инфу в имя файла" - меньшее зло, ибо "хоть что-то, хоть как-то, везде работает и прямо сейчас", а не в далёком светлом будущем.
> Имя файла, пардоньте, при копировании по сети и/или на другую ФС не уродуется (при условии, что на принимающей стороне нет проблем с кодировками и длиной имени файла).Во-во. Маааленький (и "редкий") такой пунктик с кодировками из серии "а так все хорошо, прекрасная маркиза" ;)
Кстати, а ведь можно было бы сохранять в теге типа "encoding" ;)> А метаданные как в общем случае передавать?
Вас не смущает наличие и передача метаданных в MP3 или tar/zip?
> Вон, в NTFS альтернативные потоки данных есть - хошь метаданные пихай,
...
> Вот тупо будет пара файлов - filename.ext и filename.ext.metadata.
> И кто этим пользоваться будет, даже если какая-то контора масштаба межделмаша международный
> стандарт продавит? А никто.
> Потому "пихать инфу в имя файла" - меньшее зло, ибо "хоть что-то,
> хоть как-то, везде работает и прямо сейчас", а не в далёком светлом будущем.Вот это я и подразумевал под
>"Еще бы их поддерживали не на "от#бись"и
> ухода от "мы давно привыкли запихивать все в имя файла, нам все норм"Нормальная поддержка предполагает кроме "внутресистемной" и копирование (части) атрибутов по умолчанию в каком нибудь общем формате для "экспорта".
Хотя бы "header:size, метаданные, данные". Открытие-чтение через ОС-АПИ или распространенную либу. Ведь с тем же zip особых проблем не возникает.
На уровне ФС это по сути (в самом простом варианте) еще один файл в директории с триплами "inode, value:key" - главное чтобы оно "на всех уровнях" поддерживалось.А так да, "пропихивать" желательно было еще до массового распространения компов или хотя бы в начале 2000х (концепту тегов в ФС, если мне не изменяет память, все равно намного больше лет).
Сейчас сделать что-то уже намного тяжелее - "мы не привыкли, да и деды обходились без! Не нужно!" :)
> Вас не смущает наличие и передача метаданных в MP3 или tar/zip?Смущает. Потому что формат тех метаданных привязан к конкретному типу файла, и произвольное приложение, не знающее о формате тех же mp3, не сможет эти метаданные прочитать.
И какое именно mp3? Прямо поток mp3 с тэгами id3? А какой версии тэги? А если у нас mp3 завёрнут в RIFF (.wav)? Или в .ogg? Или еще во что? И в каждом контейнере добавляется свой формат метаданных.
У TAR, кстати, как минимум два несовместимых между собой варианта (GNU и какой-то более старый, забыл правильное название).
У ZIP тоже куча версий.
А есть еще вагон всяких закрытых форматов, спецификации на которые и за деньги-то не всегда дают.
>> Вас не смущает наличие и передача метаданных в MP3 или tar/zip?
> Смущает. Потому что формат тех метаданных привязан к конкретному типу файла, и
> произвольное приложение, не знающее о формате тех же mp3, не сможет
> эти метаданные прочитать.Произвольное приложение не сможет и mp3 прочитать, так что тут никакого "убытку". Конвертеры в разные варианты опять же есть.
Про проблемы с тегами я тоже не понаслышке знаю ;), но вообще, "срукожопить/испортить" можно что угодно -- зато если с id3 тегами все нормально, получаем хорошую музыкальную библиотеку, не привязанную к конкретному софту.> У TAR, кстати, как минимум два несовместимых между собой варианта (GNU и
> какой-то более старый, забыл правильное название).
> У ZIP тоже куча версий.Это понятно. Но во-первых - я ж больше помечтать о том, что можно было бы сделать весьма простыми средствами.
Во-вторых - в повседневной жизни с tar/zip все же проблем возникает на удивление мало (для такого обилия различных форматов). Тем более, в пределах одной системы.
В-третьих, тут ведь надо всего-то экпортировать ключ:значение и сойтись на использовании пары десятков имен для ключей (там author, title, hash, keyword).
> Произвольное приложение не сможет и mp3 прочитать, так что тут никакого "убытку".тоесть через find вы уже не найдёте свою песенку если формат имени файла будет не артист-альбом-название_песни.mp3
но меня это положение дел очень не радует
с тем же видео я бы хотел иметь не файл mkv с зашитыми в него дорожками, а набор файлов с видеодорожками (разных форматов, разрешений, степени пожатия), аудиодорожками (разные варианты озвучки), субтитрами (разные варианты, разные языки), метадатой
и чтоб этот набор программы воспринимали связаннозы: кто сказал "директория двд-дорожек"(забыл как этот формат звать с кучей файлов в папке)?
>> Произвольное приложение не сможет и mp3 прочитать, так что тут никакого "убытку".
> тоесть через find вы уже не найдёте свою песенку если формат имени
> файла будет не артист-альбом-название_песни.mp3В смысле xattr или в ID3?
В первом случае поэтому и ратую за поддержку (в яблочной версии find она, говорят, даже есть), хотя оно костыляется и c помощью "find . -exec xattr что-то там".
Для ID3 тоже никто не мешает читать дополнительную информацию, которая не хранится в ФС, отдельно - что-то типа:
% find ~ -type f -iname "*.mp3" -exec mp3info -p "Artist:%a Year:%y %F\n" {} \; 2>/dev/null|grepi
> Правда какой-нибудь SHA-512 уже не влезет, но его можно через base64 прогнать и тогда влезет.Учимся считать: 512 бит это 64 байта, в HEX-виде один байт записывается двумя символами, значит нужно 128 символов (однобайтных). Что у тебя не влезет?
При двух, ага. А вот для китайских или японских символов это оказывается всего 85. Причем не обязательно брать именно их алфавит, они бывают в названиях используют "широкие" варианты английских символов/цифр/знаков препинания （１２３４；Ｖｏｔ ｔａｋ！）И, внезапно, лимит в 85 символов после виндового в 255 UTF-16 символов реально мешает представить в линуксовых ФС имеющиеся имена. Хотя одной ФС тут не решить, проблема-то на уровне ядра, где NAME_MAX это 255, а в POSIX путь это всегда байты, а не широкие символы. И вроде как никто не пытался проверять, что будет если этот лимит поднять (в смысле насколько плохо станет софту).
Вообще я неоднократно сталкивался с необходимостью урезать имена, созданные в винде. Это, конечно, специфичные случаи, но бывают.
Эта константа видна на уровне пользователя, её не так просто изменить, если вообще реально.
Эту константу можно было увеличить при проектировании следующей версии. В реальности же имеем старый добрый ext2 с журналированием.
> константа
> не так просто изменить/0
Это не на имя, а на весь путь.
нет. на весь путь 4К
>что 255 байт (именно байт, а не символов Unicode) на имя файла - это как-то совсем уж мало.Так, может, при переходе в режим UNICODE, считаться уже будут символы, а не байты.
Расскажите (нет, ну серьезно) что у вас за имена такие?
> Расскажите (нет, ну серьезно) что у вас за имена такие?
$ ( mkdir 1 && cd 1 && N=1 && while :; do if [ -e "$N" ] || ! touch TODO "$N"; then echo "вот \"$N\" такие, ${#N}"; break; else N="$N$(date +%1N)"; fi; done )
touch: невозможно выполнить touch для '1777777778888888888888888888888888888888888888888888999999999999999999999999999999999999999999990000000000000000000000000000000000000000000000111111111111111111111111111111111111111111111222222222222222222222222222222222222222222233333333333333333333333333': Слишком длинное имя файла
вот "1777777778888888888888888888888888888888888888888888999999999999999999999999999999999999999999990000000000000000000000000000000000000000000000111111111111111111111111111111111111111111111222222222222222222222222222222222222222222233333333333333333333333333" такие, 256
$ _
Ждем новых порций говнокода от школь^Wразработичков использующий для кодинга case-insensitive раздел
А разве его раньше не было? Сколько раз видел виндоразрабов, коммитящих и подключающих модули в разных регистрах, а потом это добро доблестно взрывалось на продакшне.
>А разве его раньше не было? Сколько раз видел виндоразрабов, коммитящих и подключающих модули в разных регистрах, а потом это добро доблестно взрывалось на продакшне.Так они в проприетарщину коммитили, а теперь и в опенсорц пойдет г-но
угу, и в ридми будет 0. отключите поддержку case sensitivity для нашего прекрасного проекта или не жалуйтесь, что ничего не работаеткак годами альтернативно-одаренные поступали с selinux - даже в тех случаях, когда достаточно было минимальной аккуратности в том что и как делаешь, никакой необходимости в писании наколеночных модулей (хотя и это не бином ньютона)
> а потом это добро доблестно взрывалось на продакшне.В тестирование не смогли?
"У меня на ноутбуке все работало"
Если кто разворачивает систему сразу на прод, пенять на разрабов ему следует в последнюю очередь.
Ой нехорошо это. Что-то грядёт.
Что именно может "грясти"?
И какие еще предзнаменования?
И как жить то дальше (если гром бухнет?)
А да давно уже все стало пофиг ибо все равно хуже уже не будет, после всех свистоплясок с названиями интерфейсов, с отменой iptables и внедрением systemd с PulseAudio перешел с режима что там новенького придумали на режим а ну как-то с этим дерьмом надо жить дальше...
Ребята то не в курсе что таблицы отменили, используют зачем-то. Еще и ifconfig с netstat небойсь из могилы раскопали, вот стыд
А почему это ifconfig и netstat в могиле? У меня они во всю работают!
>хуже уже не будетКаждый день так думаю. И каждый следующий день понимаю что ошибался.
>как-то с этим дерьмом надо жить дальшеЭто точно
В день преподобного мученика Стефана земля налетит на небесную ось!
> UTF-8а раньше, разве, не было? Как же на данный момент храниятся юникодовые имена?
Тоже этот вопрос одолевает...
Особенно в свете того, что любой уважающий себя линухятник считал за должное пнуть BSD и её [по их нескромному мнению] "запоздалую" поддержку UTF-8 в консоли. Вот только у ZFS с UTF-8 всё Ok от рождения by design. А тут в "божественную" ext4 внизапна какие-то патчи. Чудны дела твои, господин оторвальдс...
вот смотри: есть символы 'ы' и 'Ы', это одна и та же буква в разном регистре. для ядра это последовательности байт 'd1 8b' и 'd0 ab'. чтобы определить, что эти последовательности обозначают одну и ту же букву, ядро должно знать, как интерпретировать такую последовательность байт, а также иметь какую-то таблицу соответствия больших и маленьких букв.
для простого сохранения имени файла достаточно было сохранять последовательность байт, а вот для того, чтобы отличить буквы разных регистров, уже нужно уметь работать с кодировкой
> для того, чтобы отличить буквы разных регистров, уже нужно уметь работать с кодировкойДля того, чтобы отличить, как раз не надо. Надо для того, чтобы не отличать.
Я уже разлуркал, что ext на сей момент не заботят имена и они кое-как показываются чем-либо использую локаль из LANG, которая, к счастью, нынче x.UTF-8
> нынче[обычно ставится]
На данный момент текстом имена не хранятся. Хранятся ничего не значащие байты, к которым не предъявляется (почти) никаких требований.
>> UTF-8
> а раньше, разве, не было? Как же на данный момент храниятся юникодовые
> имена?Все имена файлов в -- последовательности байтов.
Кроме некоторых. Про них нам расскажут адепты культа дохлого 8.3...
...прямо тут--->>>
Вот чего не хватает, дак это ZSTD. А работать с файлами без учета регистра все утилиты и так давно умеют.
https://github.com/dm-vdohttps://access.redhat.com/documentation/en-us/red_hat_enterp...
https://www.redhat.com/en/blog/look-vdo-new-linux-compressio...
RedHat only
Что за бред? Это полностью открытая технология. GPLv2 лицензия. То, что редхат потрудился над интеграцией этого в свой дистрибутив, а авторы вашего нет - уж явно не проблема редхата. Требуйте от авторов вашего дистрибутива того же, или меняйте, голосуйте рублем, так сказать. Ну или сами интегрируйте, вместо стонов "redhat only"...
Какой стон? Это не стон, а просто замечание. Не будьте столь негативны :)А вообще суть замечания скорее в том, что это не в ванильном ядре, а сторонняя поделка.
Выглядит как костыль. Наверно поэтому и нет во всех дистрибутивах...
> Выглядит как костыль. Наверно поэтому и нет во всех дистрибутивах...Костыль или нет, но видимо рабочий. Хотя работа на блочном уровне без информации, где какой файл, а где вообще метаданные это весьма грустно, и, как видно по бенчмаркам, дает большой удар по производительности. А единственная другая бесплатная рабочая альтернатива (zfs) имеет нерешаемые проблемы с лицензией, что с некоторой точки зрения делает ее еще большим костылем (в плане, что можно поставить RHEL или Centos и иметь гарантированно рабочий vdo из коробки, а zfs - нельзя, и перспектив улучшения не видно). Остальные альтернативы либо объективно небезопасны (btrfs), либо предлагаются в некоторых коммерческих решениях за весьма большие деньги, что может и сводить на нет экономические выгоды от сжатия, и просто создает громадные проблемы с доступностью.
Ну а на безрыбье и рак рыба )
zfs и btrfs - монстры. Первой нужно очень много памяти для нормального функционирования. Вторая в принципе медленная. Сколько не тестировал её phoronix, результат всегда один - значительное отставание от ext4. Ценность данных систем в фишках, но не в скорости. EXT4 же лёгкая система, идеальна для десктопа.
Ты типа истина в последней инстанции или как?
Он просто озвучил факты. Для многих истиной в последней инстанции они являются. Как для вас - решайте сами.
> Он просто озвучил факты. Для многих истиной в последней инстанции они являются.
> Как для вас - решайте сами.Какие факты он озвучил? Пруфы где? Он озвучил своё IMHO, не более. Кончайте балаболить, заколупали уже своим "экспертными" умозаключениями.
он просто перепевщик стандартных urban legends, читатель похороникса.не работал ни с тем, ни с другим, ясен пень.
Как ни странно, но из неверных предпосылок сделан верный вывод - "на пятнадцать лет устаревшее ненужно идеально для на пятнадцать лет устаревшего ненужно".для "как в виндовс" и "десктопа" вполне сойдет ext4. ну вот да, имена файлов надо увеличить хотя бы до гигабайта - ворд именует файлы по содержимому первого абзаца, наивно рассчитывая на заголовок, а там, возможно, гигабайтная простыня без единого разрыва.
Вижу на данный пост претендуешь ты?
Оно просто раньше проприетарным было, а редхэт заопенсорсил после покупки компании-разработчика лишь около года назад. Возможно, через некоторое время причешут и предложат в апстрим.
lz4
ЗАЧЕМ?
потому что могут. в ластоногое ведро сейчас можно нести любую чушь - линус подобрел на старости. ТПРЬ МЖНО!!1
всегда было можно. Условие - вашу чушь нужно уложить в патч на три строки, чтоб линусу было удобно и приятственно его смотреть, и она не должна затрагивать что-то что sponsored by redhat.Кстати, заметьте, этот подарок принес нам лично T.Ts'o
Впрочем, посмотрите как реализован dirhash - и ничему уже не удивляйтесь.
> Кстати, заметьте, этот подарок принес нам лично T.Ts'oЧто-то не заметили.
From: Gabriel Krisman Bertazi <krisman@...labora.com>
это "многочисленные просьбы от имени групп трудящихся". К счастью, не имеющих пока права комитить свои просьбы напрямую.
Это не только тупо, но еще и медленнее. Привод юникодных символов к одному регистру требует дополнительных затрат
> Это не только тупо, но еще и медленнее.Медленнее чем что?
Вот смотри, есть например wine. Wine -- это реализация win32api, созданная для того, чтобы вендопрограммы запускать. Вендопрограммы предполагают регистронезависимость. А это значит, что неплохо было бы, реализовывая всякие вендовые функции работы с файловой системой, обеспечить работу с регистронезависимыми путями. Но если так, то даже элементарный OpenFile превращается в огромного монстра, который берёт путь к файлу из аргументов, и начинает идти по нему регистронезависимо. На каждый элемент пути потребуется, я полагаю, 3+ сисколла (открыть директорию, прочитать директорию, закрыть директорию).
Когда же это делает ядро, то вся эта работа выполнится в два переключения контекста: один раз в ядро через open(2), и один раз обратно.
> есть например wineВот только как вайн будет узнавать, включен ли на директории этот новый флаг или нет? Ведь без него нужно оставить старое поведение (с преобразованиями).
А проверка что флаг включен это как минимум дополнительный сискол.Так же, использование этого флага на каталогах куда ходят линуксовые программы (например если ~ или /tmp в вайн пробросить) может вызывать всякие странные глюки, т.к. подавляющее большинство таких программ не будет готово к такому поведению фс.
В итоге это будет использоваться только в каких-то узкоспециализированных случаях, например в каком-нибудь дистрибутиве заточенном под игры в wine или там в NAS.
>> есть например wine
> Вот только как вайн будет узнавать, включен ли на директории этот новый
> флаг или нет? Ведь без него нужно оставить старое поведение (с
> преобразованиями).
> А проверка что флаг включен это как минимум дополнительный сискол.Это можно прописать в настройках. Вот есть у тебя ~/.wine/drive_c, в настройках прописано дефолтом что он case insensitive, и wine создавая его и все его поддиректории проставляет флаг. А потом он может даже не проверять: если пользователь достаточно продвинут, чтобы скинуть этот флаг, то значит он должен быть готов к последствиям.
wine вообще может оставить эту проблему на внешние программы -- хочешь, настраивай регистрозависимость так, как хочешь. Тыкни на директорию и скажи, что она со всеми поддиректориями регистронезависимая, и утилитка рекурсивно изменит флаг. Тыкни на поддиректорию и скажи что она регистрозависимая, но нерекурсивно. И настраивай всё как хочешь. А wine просто тупо будет оставлять эти вопросы на усмотрение драйвера файловой системы.
Вон, как пишут в комментах, венда в ntfs умеет в регистрозависимость. И пользователь может рулить этой регистрозависимостью как хочет. То есть если wine свалит вопросы регистра на ядро, то он устранит все различия с вендой в этом плане. И получит бонус к производительности, потому что не надо будет пользоваться юзерспейс костылями.
> Так же, использование этого флага на каталогах куда ходят линуксовые программы (например
> если ~ или /tmp в вайн пробросить) может вызывать всякие странные
> глюки, т.к. подавляющее большинство таких программ не будет готово к такому
> поведению фс.Подавляющее большинство программ ничего не заметит. Возьми coreutils, например, те берут имея файла из argv, открывают этот файл, что-то с ним делают, закрывают. Им совершенно фиолетово, регистрозависимо оно или нет. А какой-нибудь там ls, который имена файлов берёт читая директорию, тоже не заметит ничего особого. Ну прочитал он имена файлов, и чё? Там какие-либо аберрации могут возникать тогда, когда есть два разных источника для имени файла и они дают имя файла в разных регистров. Но что именно? Возьмём cp: мы сказали cp /tmp/file .; в /tmp этот файл на самом деле назван как File, а в ./ тоже есть файл с именем FILE, в результате конечный регистр имени файла в ./ будет зависеть от деталей реализации cp. Может быть мы получим ./file, может быть ./File, может быть ./FILE. Ну и чё? Это называется UB, и как правило это не страшно. Это будет страшно если ты начнёшь писать заморочные скрипты, не учитывая этих UB.
Но и тем не менее, подавляющее большинство программ ничего не заметит. А если каким-то образом в линуксе станет модно использовать регистронезависимую фс (во что я не верю впрочем), то эти программы поправят с тем, чтобы они умело обрабатывали бы такие случаи.
> В итоге это будет использоваться только в каких-то узкоспециализированных случаях, например
> в каком-нибудь дистрибутиве заточенном под игры в wine или там в
> NAS.Или в веб сервере, чтобы тот мог бы хранить файлы с именами в тОм РеГиСтРе в котором они были залиты на сервер, но при этом сохранять агностичность к регистру символов в url'ах. Или общесистемно, дабы никому в голову не приходила глупая идея создавать файлы с одинаковыми именами, различающимися лишь регистром.
Таких узкоспециализированных случаев может возникать много разных. И если их все объединить в одну группу, то эта группа случаев может оказаться не такой уж и малой. Но даже это не очень важно, потому что linux давно уже пытается быть бочкой во всех затычках. Технологическая проститутка.
Но и это не очень важно. В чём собственно проблемы? Ну поддерживает linux какие-то узкоспециализированные случаи, которые тебе не нужны, тебе-то что с того?
> только как вайн будет узнавать, включен ли на директории этот новый флаг или нет?README.shit-d
0. включите или ничего работать не будетсейчас так принято.
> А проверка что флаг включен это как минимум дополнительный сискол.
а case-insensitive поиск по fs с учетом локали - это семечки. Включая даже и просто банальную проверку if (nocase) {} - выполняемую при массовых поисках миллионы раз в секунду, даже если фича тебе нахрен вот вообще не сдалась.
Заставляли бы всех любителей 1 windows way просто использовать ntfs3g, я был бы счастлив. Заодно, может, код бы чуток обновили, хотя...не, с этими руками лучше не надо.
> На каждый элемент пути потребуется, я полагаю, 3+ сисколла
> (открыть директорию, прочитать директорию, закрыть директорию).Нет такого слова в русском языке "директория".
> Нет такого слова в русском языке "директория".Увы:
https://ru.wiktionary.org/wiki/директория
Ну или
> Толковый словарь Ушакова
> ДИРЕКТОРИЯ
> ДИРЕКТОРИЯ, директории, мн. нет, ж. (полит.). Коллегия директоров (во 2 знач.), правителей государства, напр. в эпоху Великой французской революции (1795 - 1799),
> контрреволюционная организация в эпоху гражданской войны (на Украине, в Уфе).Я вообще краем уха слышал, что носители языка его постоянно меняют, подстраивая под современные реалии ;)
>> На каждый элемент пути потребуется, я полагаю, 3+ сисколла
>> (открыть директорию, прочитать директорию, закрыть директорию).
> Нет такого слова в русском языке "директория".Это проблемы русского языка, это не мои проблемы.
На фоне приложений на антиэкологичных bloatlangs (java, python, etc) выглядит как нытье по волосам после потери головы. Хотя лично я не вижу смысла в регистронезависимости...
>требует дополнительных затрати дырявых парсеров с переполнениями[I]!
Начиная читать новость после заголовкая меня посетила буря эмоций, ну как же так?! И что, теперь в наших линуксах File и file будут одним и тем же файлом?!С другой стороны, мы же подобны ретроградам, которые всюду противятся новшествам. Да, будет такой флаг в ФС, но это добавит гибкости. Хочешь — используй. Не хочешь — ну так и не rwx единым, добавим сюда suid и скорее всего он тоже доставил проблем в прошлом.
Всегда есть альтернатива и что-то новое — это и есть этот прогресс, это и есть то, ради чего мы юзаем опенсофт и котрибьютим по возможности.
Это не прогресс, а регресс.
Взяли бы что полезное, например сжатие там или нормальные (per directory) квоты сделали - милости просим. А так, завезли костыль, тянущийся ещё со времён доса (или раньше?).
> Взяли бы что полезное, например сжатие тамА что, кстати, мешает? Где оно, сжатие в ext4 или xfs на уровне файлов (а не блочном уровне как в vdo)? btrfs не предлагать.
Вон в NTFS уже несколько по-разному реализованых механизмов сжатия выкатили. К историческим несколько лет назад добавили новый через reparse points с кучей (неплохих - современных, эффективных и параллелящихся) алгоритмов на выбор. Да и еще во времена ext2 были экспериментальные (но вполне рабочие, сам использовал во времена 2.2) патчи для поддержки атрибута +c (e2compr). И где оно сейчас?
На уровне файлов не годится точно. Базы данных такого не потерпят. Нужно на уровне блоков. И есть предположение, что EXT4 придется полностью переписать, чтобы внедрить сжатие. Т.е. этот косяк заложен в архитектуру, не предусмотрели.
Блин, ну разумеется технически сжатие поблочное ) я имею ввиду, что контролироваться на уровне файлов и работать только с блоками данных, а не физическими блоками диска где и метаданные и все остальное. В VDO вон сжатие как раз поблочное, но на уровне своих блоков в device mapper, оно не знает где там что в ФС - отсюда проблемы.
Тебя не смущает, что этот «костыль» продолжает тянуться столько лет и всё ещё кому-то нужен? Вдруг — ну просто в порядке мысленного эксперимента предположим — человекам удобнее, когда File, file и fIlE — это одно и то же? Я, к слову, не могу придумать ни одной реальной задачи, при которой мне могло бы понадобиться иметь два объекта файловой системы с почти одинаковыми названиями, отличающимися только регистром. Зато я регулярно удаляю директорию ~/Downloads, создаваемую каким-то сердобольным софтом, который именно в силу регистрозависимости не видит уже существующую директорию ~/downloads. Если хорошо подумать и поставить удобство пользователя на первое место, то вся история с регистром сведётся к простому правилу: регистр хранить, но не учитывать.
> — человекам удобнее, когда File, file и fIlE — это одно и то же?А почему бы с такой же логикой не считать 0, O и О за один и тот же символ? Пишуются же похоже.
А раз у нас UTF-8 и в ней куча символов которые отображаются одинаково, то может тоже их всех между собой объединим?
И пробелы с табуляцией (и другими "пробельными" символами) тоже.> Я, к слову, не могу придумать ни одной реальной задачи, при которой мне могло бы понадобиться иметь два объекта файловой системы с почти одинаковыми названиями, отличающимися только регистром
Есть два имени файла:
"Файл " и "Файл "
стоит их считать за один по твоему или нет?> Если хорошо подумать и поставить удобство пользователя на первое место
Удобство тут мимо. Человеку, если он не помнит точное имя файла, нужно предоставлять возможность делать поиск файла, а для хорошего поиска сделать нечувствительность к регистру недостаточно, не понятно почему именно эту функцию __поиска__ нужно впихивать в ФС.
Ну давайте тогда поиск по разным словоформам впихнём туда, ведь человку будет удобнее набрать "~/документ Васи.txt" и получить "~/Васин документ.txt".
>> — человекам удобнее, когда File, file и fIlE — это одно и то же?
> А почему бы с такой же логикой не считать 0, O и
> О за один и тот же символ? Пишуются же похоже.Кстати, да!123
"Человекам" ещё удобно не создавать файлов C:\CON, D:\CON, C:\NUL, D:\NUL, C:\TEMP\CON, D:\TEMP\NUL. [I]Уф, вроде все вспомнил.
> Уф, вроде все вспомнил.Ещё AUX и PRN же ;)
>> Уф, вроде все вспомнил.
> Ещё AUX и PRN же ;)Я ж тэг поставил. :-P Там ещё "несколько" пропущены:
$ time echo {E..Z}:\\{A..Z}{,{A..Z}{,{A..Z}{,{A..Z}}}}\\{NUL,CON,{LPT,COM}{1..4}} |wc -w
bash: xmalloc: .././braces.c:802: cannot allocate 14 bytes (3988856832 bytes allocated)
0real 0m25,218s
Нет, не все. Еще есть:
" "
" "
...
". "
". "
...
".. "
".. "
...
и особенно класно в конце имени файла поставить 0xff. Делаю так, чтобы потроллить шиндузятников.
> А почему бы с такой же логикой не считать 0, O и О за один и тот же символ? Пишуются же похоже.
> А раз у нас UTF-8 и в ней куча символов которые отображаются одинаково, то может тоже их всех между собой объединим?Абсолютно верное замечание. Я бы к нему добавил бы запрет на системном уровне на установку моноширинных говношрифтов, у которых не отличить 1 от l.
>С другой стороны, мы же подобны ретроградам, которые всюду противятся новшествам.Полезным новшествам обычно не противятся.
Ждём новых уязвимостей.
C:\
FoRmAt c:
На самом деле:/DosDevices/C:
Сюрприз-сюрприз ;-)
C:\Linux\System32\libc.so
> C:\Linux\System32\libc.soЭто так было в Windows 96
А в Windows NT вот так:
/SystemRoot/libc.so
>> C:\Linux\System32\libc.so
> /SystemRoot/libc.so%SystemRoot%/Libc.So.DLL
>>> C:\Linux\System32\libc.so
>> /SystemRoot/libc.so
> %SystemRoot%/Libc.So.DLLПеременные окружения (%SystemRoot%) работают на уровне выше. Ядро и Native API понимают именно /SystemRoot/libc.so
Наконец-то вайн нормально заработает. А то с васянскими репаками фш вечно приходилось городить лишний образ с нтфс, чтобы он встал и запустился.
А чем тебе плох GIMP? :)
Один из примеров это мода верстать сайты из PSD-шаблонов во всяких конторках.
Это подготовка к переводу windows на linux kernel
DOS возвращается. Ждём 8.3.
Выше требуют аналог LFN
JFYI в OS/2 были регистрозависимые длинные имена файлов даже на FAT12.
...которые хранились в отдельных файлах "ea data.sf" (название мог перепутать - давно дело было) в каждом каталоге.
> ...которые хранились в отдельных файлах "ea data.sf" (название мог перепутать - давно
> дело было) в каждом каталоге.Да. И там могли хранится не только длинные имена, но и другие метаданные. например иконки.
А на HPFS имена 8.3 отдаваемые в dos сессию хранились в EA
Главное чтобы зловредную логику переименования файлов не принесли (в винде и гите чтобы переименовать файл, только поменяв регистр символов, надо переименовать, не тол ко поменяв регистр, а потом ещё раз переименовать, отменив нерегистровые изменения).
Это точно. Надеюсь не перетащат это.
Что-то фак животворящий по поводу регистронечувствительности запоздал.
Фак был предъявлен ещё в районе 2014, и мартышки названы мартышками. См. ссылку на статью из cio.com выше.
Данная реализация выглядит достаточно изолированной, чтобы не ломать имеющееся. Я бы даже притащил такое на локалхост во всякие "/bin/", т.к. иметь там нечто *не* в нижнем регистре — явная проблема. А ОчепятатьсЯ, напротив, легко. Как в vim ':Q': левая тупо не успела отпустить shift. (Потому что у марсиан шифт лочился до следующего символа и им было нормально.)
Контрольные суммы для коррекции ошибок для блоков данных будут когда-нибудь?
Или когда хоть dm-integrity будет доступно без заката солнца вручную?
Когда увеличат ограничение на полное имя пути файла в линуксе?
Вам зачем, расскажите? Что можно накреативить, чтобы не хватило 4х килобайт для полного пути?
Ингредиенты - файловая шара в офисе, обычные офисные работники, обычные офисные документы.
> Ингредиенты - файловая шара в офисе, обычные офисные работники, обычные офисные документы.Катализатор — начисление и снятие премий. За месяц обучатся, самые тупые за два. Остальные в принципе не пригодны к выполнению хоть каких-то задач, задействующих КБП головного мозга: уволить.
Ага, еще колючая проволока с напряжением...
Вообще-то, нормально, когда технологии для бизнеса, а не наоборот. Тем более, что RH за это деньги берёт...
Порой, даже файлы с переносного жестака на линуксовую машину не перебросить. Ограничение нелепейшее, а цель его - непонятная.
>Вообще-то, нормально, когда технологии для бизнеса, а не наоборот.Бизнес не пробовал нанимать вменяемых сотрудников, а не чьих-то родственников?
>Порой, даже файлы с переносного жестака на линуксовую машину не перебросить.
Надо мозг включать, когда файлы называешь — реально помогает.
>Ограничение нелепейшее, а цель его - непонятная.
Цели у него и нет. Бесконечно длинное имя у файла технической возможности выставлять не было, остановились на вполне разумном ограничении/
я пробовал - родственники обижаются.А учитывая что другие родственники этих родственников могут наслать чуму, холеру и пожарную безопасность - лучше их зря бы не обижать.
> Надо мозг включать, когда файлы называешь — реально помогает.
окститесь, дорогой лап4атый, кроме вашего маня мирка так никто уже не делает - как прекрасный ворд назвал, так и назовется. И положится в Новая папка(254)
> Бесконечно длинное имя у файла технической возможности выставлять не было
а меня не колебет - немедленно почините и должите об исполнении!
Сделали бы хотя бы настраиваемым параметром, а то так можно вернуться и к 8-bit fat.
После клиентских приложений на java, python, etc, ограничение длины пути в 4096 байт выглядит нелепым...
"Вам зачем, расскажите? Что можно накреативить, чтобы не хватило 4х килобайт для полного пути?"
Не вам зачем, а надо посмотреть сталкиваются ли люди с проблемами. А люди сталкиваются.
файлы с именами в cp1251 на рутрекере -- приходится флешку с фатом постоянно в компе держать.
Почему-то регистрозависимость преподносилась как что-то правильное.Но:
кейс 1: люди сами создают файлы-папки с человекопонятными именами. И если есть возможность создать Файл и файл, это очевидно плохо. Жамкать шифт тоже не очень приятно.
кейс 2: вот эти самые хрени 13fg6-65Ghu-.. Наверное, иметь возможность регистрозависимости для них было бы неплохо, можно сэкономить длину, если охото.Я понял что это не правильно. Конечно, если на уровне ФС Файл и файл - разные файлы, то нужно CS. Но нужно чтобы вообще нельзя было создать Файл, фАйл и т.д., если есть файл.
>Но нужно чтобы вообще нельзя было создать Файл, фАйл и т.д., если есть файл.Кому нужно?
всем нужно. Чтобы какая-нибудь толстая северная птица не создала его, а ты бы потом не обратился случайно к другому файлу. Компуктер - его для людей придумали. Можно конечно открывать директорию, смотреть, что там есть, но зачем, если я знаю что в папке папка лежит файл файл, но забыл с большой буквы или маленькой.
Причем такой файл может быть создан без злого умысла, просто через файл, сохранить как, вбили имя какое хотелось, и все.
>всем нужноМне — нет.
>Чтобы какая-нибудь толстая северная птица не создала его, а ты бы потом не обратился случайно к другому файлу.
И каким же образом я «случайно» обращусь не к тому файлу? Я вижу только один сценарий: оригинал будет удалён, а мне придётся использовать ущербную систему, не умеющую в регистры. Но, собственно, в чём проблема-то? Закрыл ненужный и открыл нужный.
>Причем такой файл может быть создан без злого умысла
Палишься, виндоюзер. Открою тебе секрет (который на самом деле не секрет, но ты вот не в курсе): если к компьютеру и его данным имеет доступ абы кто, то развесёлый приключения не предотвратить никак. А от «доброго неумысла» спасают разные учётки БЕЗ админских/рутовых прав и лок экрана при отсутсвии (условного) владельца компьютера рядом.
> каким же образом я «случайно»Абсолютная память? Если файл создали, написали скрипт, где забито его имя, то, конечно, никак.
А если создали, забыли, через 100 лет понадобился - запросто. Конечно, как правило, при этом "понадобился" виден список файлов, но он может быть отсортирован не по имени.> Палишься, виндоюзер. Открою тебе секрет (который на самом деле не секрет, но
> ты вот не в курсе): если к компьютеру и его данным
> имеет доступ абы кто, то развесёлый приключения не предотвратить никак. А
> от «доброго неумысла» спасают разные учётки БЕЗ админских/рутовых прав и лок
> экрана при отсутсвии (условного) владельца компьютера рядом.Кейса 2:
- пользователь ДОЛЖЕН иметь доступ в эту папку (бывают такие вещи, типа, это, локальной корпоративной сети). Но он и создаст там что-то безобидное, и прав на выполнение там не будет. Но мне жаль и 1/3 секунды времени потерянного с ничтожной вероятность возникновения такого кейса, чтобы че-то там закрыть/открыть лишнее- а кейс по безопасности - его как бы и нет. Доступ туда где может лежать что-то исполняемое есть только у кого надо.
P.S. Я все это время говорил про элементарный бардак, о том, что не зачем было делать доп. возможность испортить порядок.
А мне рассказали и про то что я виндоюзер и что байты хочу сэконимить, а зачем при обращении к файлу обязательно воспроизводить все его заглавные буквы (и иметь возможность иметь 2 разных файла Файл и файЛ как следствие) не рассказали. Неужели только для того, чтобы написать как самому нравится и чтобы все потом так же писали и не могли капсом там или как они любят изгаляться?
> Абсолютная память?Она у меня просто есть. Обычно этого достаточно.
> А если создали, забыли, через 100 лет понадобился - запросто.
Сто лет? Я меньше живу пока что. Да и «создать файл» стало возможным не век назад.
Что вообще за дичь ты несёшь?
Почему file и File с твоей точки зрения можно легко перепутать, и это ужас-ужас, а file01, file02, file03 и т.д. перепутать/забыть никак невозможно, и никакими страшными последствиями это не грозит?>но он может быть
> отсортирован не по имени.Ужас-то какой, целый хоткей нажать! А то и два: для сортировки по имени и для выстраивания по возрастанию убыванию!
А если ещё группы/фильтры задействовать — вообще rocket science!> Кейса 2:
> - пользователь ДОЛЖЕН иметь доступ в эту папку (бывают такие вещи, типа,
> это, локальной корпоративной сети). Но он и создаст там что-то безобидное,
> и прав на выполнение там не будет. Но мне жаль и
> 1/3 секунды времени потерянного с ничтожной вероятность возникновения такого кейса, чтобы
> че-то там закрыть/открыть лишнееНичего не понял. Чего создаст, кто создаст, какого лешего он это что-то назовёт не пойми как — чтобы наверняка забыть? Треть секунды на нормальное имя для файла потратить лень, а потом тратить время на угадывание содержимого и решение невнятных проблем (я так и не понял, в чём они заключаются) — норма?
> А мне рассказали и про то что я виндоюзер и что байты
> хочу сэконимить, а зачем при обращении к файлу обязательно воспроизводить все
> его заглавные буквы (и иметь возможность иметь 2 разных файла Файл
> и файЛ как следствие) не рассказали.Автодополнения, фильтры? Не слышал, нет?
> если есть возможность создать Файл и файл, это очевидно плохоЭто очевидно хорошо.
> вот эти самые хрени 13fg6-65Ghu-.. Наверное, иметь возможность регистрозависимости для них было бы неплохо, можно сэкономить длину, если охото.
Такой возможности нет и не будет. И вы хотите сэкономить несколько байт из терабайтов, забитых контентом этих файлов.
Хватит бредить.
Народ негодует, как будто у них отобрали что-то? Да не ставьте этот флаг и всё будет по-старому. Наоборот, хорошо, когда есть альтернатива для какого-то механизма.
От ненужных «альтернатив» ядро уже разжирело на несколько порядков.
А кто сказал, что это плохо? Ваши аппаратные ресурсы застряли в 90х чтоли?
А если вам нужно мега-компактное ядро, ну так пересоберите, делов-то. Там процедура несложная вовсе.
Вы что! Это же лишние пара сотен килобайт. Для линуксоидов это конец, у них харды то не резиновые!
>Ваши аппаратные ресурсы застряли в 90х
> чтоли?Плохо то, что каждый вопящий про «дешёвые аппаратные ресурсы» забывает, что экономить эти самые ресурсы перестаёт КАЖДАЯ из софтин, которые он разрабатывает или использует. В итоге рост мощностей за рост нагрузки частенько не поспевает.
Работаю в IT и околоIT уже скоро 20 лет как. Не могу вспонить таких моментов, чтобы вычислительных ресурсов не хватало для прода именно по причине особой прожорливости софта, а не катастрофического наплыва пользователей, например. Думаешь везло все эти годы?
Наплыв пользователей на нормальный софт незаметен, в отличие от прожорливого
> Работаю в IT и околоIT уже скоро 20 лет как. Не могу
> вспонить таких моментов, чтобы вычислительных ресурсов не хватало для прода именно
> по причине особой прожорливости софта, а не катастрофического наплыва пользователей, например.
> Думаешь везло все эти годы?Мысль расшифруй, заслуженный работник всея АйТи.
Потому как по причине прожорливости софта ресурсов не хватает сплошь и рядом, а вот какое отношение к оным имеет «наплыв пользователей» — совершенно непонятно/ Или ты смешал в кучу сервера и десктопы?
Если тебе что-то не нравится, вали на hurd.
А если в такой каталог будут скопированы файлы с более «старшим» юникодом, в котором тоже будут символы различного регистра, то что?
Press F to pay respect to windows.
Set +F
fixed
Пора уже Ext5 пилить, со сжатием и заточкой под ssd
> заточка под ssdЭто как конкретно?
COW
А что с обратной совместимостью? Как такие файлы/каталоги будут обрабатываться на машинах с предыдущими версиями ФС?
да никак :) кто нынче о совместимости думает?
кругом сплощной непрофессионализм...
А читаем мы непонятно чем. Русским же по белому написано:
1. Никаких изменений в структуре на диске нет, вся логика в функции сравнения имён.
2. Новый флаг можно поставить только на пустой каталог.
>Значение атрибута "+F" сохраняется внутри inode отдельных каталогов и распространяется на все >вложенные файлы и подкаталоги. Информация о кодировке сохраняется в суперблоке.Как будут обрабатываться новые атрибуты в inode при подключении накопителя к другой машине с предыдущей версией ФС? Как вообще будут обрабатываться такие (да, изначально пустые) каталоги?
то что какой-то софт может после этого 'сломаться' их не волнует совсем?
линус же говорил, все что влияет на юзерспейс - трогать нельзя. балаболишка :)
Разве один и тот же символ но в разном ригистре не кодируются разными юникод последовательностями? Если все-таки разными, тогда это п...ц
Ах, какая ж возможность добавить немного уличной магии в программы. Впрочем, свобода ведь...
Гораздо интереснее, когда длину имени файла сделают больше
Как всегда - у разработчиков свои, особые, уличные приоритеты. Тут уже отмечали, что работать с файлами без учета регистра все утилиты и так давно умеют. Поэтому важность этой возможности если и есть, то для каких-то очень специфичных кейсов, с ходу и не придумаешь.
Вот что действительно давно нужно и важно, так это отключение контроля прав доступа на подключаемых носителях (флешки в простонародье). В свое время даже отдельную фс для этого набросали на коленке (https://danrl.com/projects/lanyfs/), правда в ядро она так и не попала.
мы такую fs разработали в 85м году. fat называлась.
Правда, в ваше ведро ее современная версия "так и не попала", оставшись в виде патчей самсунга, но вы все же можете пользоваться ей через анус...простите, в вашей анатомии это называется fuse.только мы не понимаем, зачем - юникс-система вам явно не нужна, раз у вас возникают подобные причуды, а мы, кстати, и неплохую операционочку можем предложить, занедорого...
Бредовая затея. Средний виндовый пользователь не запоминает имена.Он запоминает положение иконки на экране. Перемешай иконки на рабочем столе, измени порядок сортировки или системный шрифт - и он пойдет звать админа, потому как "ведь всегда же открывал так". А это идея - нужно хранить в ФС не имена а каринки с начертанием имени файла.
ты не понимаешь - средний виндовый пользователь не придумывает имена (потому что не знает что это такое), он нажимает "сохранить", и долго тупит, что за непоятная хрень вылезла, после чего жмакает OK.
именем файла становится, например, весь первый абзац документа word.И да, с проблемами что "нивлазит" мы сталкиваемся под б-жественной 2016 каждый день.
Да-да, в винде - тоже нивлазит. Как?
Создаем на флэшечке оченьнужнаяхреньсречугамигенеральногодиректораодобреннымидляпубликации\всяречугегенеральногодиректораводномабзаце.doc
и пытаеся положить на серверную шару в \компаниянапятьстрок\моеподразделениепервогоуровняещенапять\ещдесятьтакихже\
- уп-с, нивлезло.оправдания вида "нет технической возможности" слушают в пол-уха - "ну вот же ж на моей флэшечке все открывается, сделайте мне чтоб работало!"
Госспаде, гора родила мышь. Нужны увеличение длины имени файлов и возможность отключения прав доступа на ext4. Но нет, они делают хуже.
>и возможность отключения прав доступа на ext4чем тебя не устраивают права доступа в лине? Как по мне всё логично и мощно!
>>и возможность отключения прав доступа на ext4
> чем тебя не устраивают права доступа в лине? Как по мне всё логично и мощно!тем, что на вставленной флешке с ext* права будут с того компа, откуда флешка (идентификаторы юзеров например)
Это зачем? Что-то, я не понял.
Так, с регистром разобрались, теперь нужно добавить буквы дисков без монтирования. Все эти A:, B: C:. В Minoca кажется было.А если серьезно - это же жуткая мелочь, кажется. Такой очень маленький патч, который никак ни на что не влияет, только на ту логику обработки имён? Нет особого вреда (или пользы).
- Алло, это Линус Торвальдс?
- Да?
- ВИНДА!