Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 79
Не «уязвимость в git», а «уязвимость в git для windows & mac». Так сказать, почувствуй разницу.
«На некоторых ФС», это не на ФАТ ли случайно?
Короче, сами себе в ногу выстрелили (я про case insensitive файловые системы).
Того, что это баг гита никто не спорит, но единственный метод его получить в продакшене — юзать кривые файловые системы.
Короче, сами себе в ногу выстрелили (я про case insensitive файловые системы).
Того, что это баг гита никто не спорит, но единственный метод его получить в продакшене — юзать кривые файловые системы.
Мне кажется, полагаться на регистрозависимые файловые системы — это как раз и есть «выстрелить себе в ногу».
Какие, вообще, в наше время преимущества у использования регистрозависимых ФС, кроме поддержки совместимости с legacy-кодом и «потому что всегда так было»?
Во времена, когда компьютеры были большими и дорогими, возможно, имело смысл экономить процессорное время и память на сравнении и поиске имён файлов — с регистрозависимыми именами файлов можно было просто и быстро сравнивать их ascii-коды без приведения к одному регистру.
Но зачем сегодня иметь возможность различать файлы file.txt и File.txt, или, вернее, зачем пользоваться этой возможностью рискуя поиметь проблемы?
В linux принято использовать регистрозависимые ФС, но, к примеру, имена серверов — регистронезависимы.
Имена пользователей в linux регистрозависимы? В файле паролей имена пользователей записываются регистрозависимо, т.е. теоретически можно создать пользователей user и User, но имя почтового аккаунта — регистронезависимо, и куда попадут письма отправленные на user@host, User@host и uSeR@host?
Ну ладно, технические проблемы можно ещё разрешить, заставить программистов и тестировщиков поработать внеурочно и повставлять, где надо, tolower(), и различать регистр, где не надо — вот совсем как разработчики git в данном случае :)
Но как только в дело вступает пользователь, мы получаем опять проблемы и путаницу — для многих файлы «my work document.doc» и «My work document.doc» — это одно и то же, ровно как и bart simpson и Bart simpson — это одно и то же имя.
Вот вы и сами в первом комментарии написали windows, хотя явно подразумевали Windows — название операционной системы, а не английское слово для обозначения окон :)
Какие, вообще, в наше время преимущества у использования регистрозависимых ФС, кроме поддержки совместимости с legacy-кодом и «потому что всегда так было»?
Во времена, когда компьютеры были большими и дорогими, возможно, имело смысл экономить процессорное время и память на сравнении и поиске имён файлов — с регистрозависимыми именами файлов можно было просто и быстро сравнивать их ascii-коды без приведения к одному регистру.
Но зачем сегодня иметь возможность различать файлы file.txt и File.txt, или, вернее, зачем пользоваться этой возможностью рискуя поиметь проблемы?
В linux принято использовать регистрозависимые ФС, но, к примеру, имена серверов — регистронезависимы.
Имена пользователей в linux регистрозависимы? В файле паролей имена пользователей записываются регистрозависимо, т.е. теоретически можно создать пользователей user и User, но имя почтового аккаунта — регистронезависимо, и куда попадут письма отправленные на user@host, User@host и uSeR@host?
Ну ладно, технические проблемы можно ещё разрешить, заставить программистов и тестировщиков поработать внеурочно и повставлять, где надо, tolower(), и различать регистр, где не надо — вот совсем как разработчики git в данном случае :)
Но как только в дело вступает пользователь, мы получаем опять проблемы и путаницу — для многих файлы «my work document.doc» и «My work document.doc» — это одно и то же, ровно как и bart simpson и Bart simpson — это одно и то же имя.
Вот вы и сами в первом комментарии написали windows, хотя явно подразумевали Windows — название операционной системы, а не английское слово для обозначения окон :)
имя почтового аккаунта — регистронезависимоНе обязательно.
«В наше время», как и в любом другое время — основные преимуещства файловых систем, которые хранят названия файлов как цепочки байт (вы их называете «регистрозависимыми») — однозначность и простота.
«Однозначность» означает, что когда работают n-ное количество разных не самых аккуратных людей, в проекте внезапно не будет бардака вида:
— qwindowtext.cpp
— qWindowText.h
— QtSocketHandler.cpp
— QTSocketWritehandler.cpp
— qtSocketReadHandler.cpp
— qtsocketaccess.h
и т.д.
«Простота» означает, что на самом деле регистронезависимость — это весьма сложная тема. Внезапно, файловая система оказывается привязанной к какой-то кодировке (причем эта кодировка скорее всего должна быть одна). Внезапно, задача коллейшена символов друг в дружку, оказывается, требует гигантских (по меркам ядра) юникодных баз данных (которые еще и регулярно обновляются по мере введения новых символов) и не самых простых алгоритмов (вот, например, ICU — это в районе 12-15 мегабайт). Внезапно, коллейшен часто зависит не только от кодировки, а еще и от языка и локали (например, с точки зрения немецкого «Mael» = «mäl», а с точки зрения татарского — это два совершенно разных слова). Есть туча вопросов, где народ до сих пор спорит, что считать одинаковым, а что — нет (например, отличие «v», «vv» и «w» в финском — в именах собственных и в обычных словах). Нужно ли отличать знаки *٭⁎∗⚹✱＊ или все их считать равными «ASCII звездочке»? И это еще самые видимые и простые вопросы юникода.
Внезапно, даже если кто-то все эти выборы сделает и будет однозначный алгоритм — как только ОС и файловая система начинает считать какие-то файлы одинаковыми по нему — во _всем_ прикладном софте придется таскать еще одну реализацию этого алгоритма, просто чтобы избегать подобных проблем, как получилось в данном случае. И то, см. выше — это фундаментально ни от чего не спасает. Завтра какой-то редкий мировой язык с 20 тысячами носителей заявит, скажем, что у него «i» = «aex», и, внезапно, ".git" можно будет записать, как ".gaext" в этой локали. И, привет, новая «уязвимость».
«Однозначность» означает, что когда работают n-ное количество разных не самых аккуратных людей, в проекте внезапно не будет бардака вида:
— qwindowtext.cpp
— qWindowText.h
— QtSocketHandler.cpp
— QTSocketWritehandler.cpp
— qtSocketReadHandler.cpp
— qtsocketaccess.h
и т.д.
«Простота» означает, что на самом деле регистронезависимость — это весьма сложная тема. Внезапно, файловая система оказывается привязанной к какой-то кодировке (причем эта кодировка скорее всего должна быть одна). Внезапно, задача коллейшена символов друг в дружку, оказывается, требует гигантских (по меркам ядра) юникодных баз данных (которые еще и регулярно обновляются по мере введения новых символов) и не самых простых алгоритмов (вот, например, ICU — это в районе 12-15 мегабайт). Внезапно, коллейшен часто зависит не только от кодировки, а еще и от языка и локали (например, с точки зрения немецкого «Mael» = «mäl», а с точки зрения татарского — это два совершенно разных слова). Есть туча вопросов, где народ до сих пор спорит, что считать одинаковым, а что — нет (например, отличие «v», «vv» и «w» в финском — в именах собственных и в обычных словах). Нужно ли отличать знаки *٭⁎∗⚹✱＊ или все их считать равными «ASCII звездочке»? И это еще самые видимые и простые вопросы юникода.
Внезапно, даже если кто-то все эти выборы сделает и будет однозначный алгоритм — как только ОС и файловая система начинает считать какие-то файлы одинаковыми по нему — во _всем_ прикладном софте придется таскать еще одну реализацию этого алгоритма, просто чтобы избегать подобных проблем, как получилось в данном случае. И то, см. выше — это фундаментально ни от чего не спасает. Завтра какой-то редкий мировой язык с 20 тысячами носителей заявит, скажем, что у него «i» = «aex», и, внезапно, ".git" можно будет записать, как ".gaext" в этой локали. И, привет, новая «уязвимость».
с точки зрения татарскогоПричём тут татарский?
Внезапно, файловая система оказывается привязанной к какой-то кодировке (причем эта кодировка скорее всего должна быть одна). Внезапно, задача коллейшена символов друг в дружку, оказывается, требует гигантских (по меркам ядра) юникодных баз данных (которые еще и регулярно обновляются по мере введения новых символов) и не самых простых алгоритмов (вот, например, ICU — это в районе 12-15 мегабайт).
Вы всё очень и очень переусложняете. За мак не отвечаю, а в винде сравнение имён файлов происходит по одному топорному алгоритму:
1. Привести строки к верхнему регистру согласно инвариантной локали.
2. Сравнить бинарно.
Никакой зависимости от языка и локали, никакой нормализации, никакой зависимости от фазы луны. И никаких магабайтов ICU, разумеется.
Никакой зависимости от языка и локали, никакой нормализации, никакой зависимости от фазы луны. И никаких магабайтов ICU, разумеется.Ага. Всего навсего зависимость от конкретной файловой системы (на служебный файл $upcase посмотрите). Причём поскольку путь у вас может проходить по нескольким файловым системам то этих таблиц для каждого файла может использоваться несколько. Это если мы на минуточку забудем, что у каждого файла и каталога могут быть два имени (короткое и длинное).
Вы уж конечно извините, но никакого преимущества у Case-Insensitive файловых систем нет, кроме Job Security: сколько бы разработчики программ ни бились, а ошибки в обработке всё равно будут, потому что «правила игры» всё время меняются.
Единственный подход, который может работать в долгосрочной перспективе это, увы, «разные последовательности байтов» == «разные файлы». Всё остальное — это в чистом виде подарок вирусописателям и троянописателям.
Не увидел по ссылке ни описания содержимого $upcase, ни даже упоминания его размера. Ну да, данные где-то храниться же должны, но в том, что существует 100500 версий файла $upcase по 10 метров каждая — не убедили. (Гуглится оно, к слову, отвратительно, так что любой информации буду рад.)
Я описал алгоритм NTFS. Что при смеси файловых систем он не работает — ну да, есть такое. Но, как вы заметили, поздно пить Боржоми, потому что у файлов и так два имени. Учитывая святую для винды обратную совместимость, для гарантированного сравнения имён файлов в любом случае придётся распарсивать весь путь, получать канонические имена и разбирать по частям. Ну не выйдет просто так сравнить строки.
Я описал алгоритм NTFS. Что при смеси файловых систем он не работает — ну да, есть такое. Но, как вы заметили, поздно пить Боржоми, потому что у файлов и так два имени. Учитывая святую для винды обратную совместимость, для гарантированного сравнения имён файлов в любом случае придётся распарсивать весь путь, получать канонические имена и разбирать по частям. Ну не выйдет просто так сравнить строки.
Не увидел по ссылке ни описания содержимого $upcase, ни даже упоминания его размера.А зачем это вам? Неужто хотите писать безопасные программы? А вот фиг вам: писатели антивирусов тоже кушать хотят.
Гуглится оно, к слову, отвратительно, так что любой информации буду рад.Да ладно вам. На первой же странице есть ссылка на статью, которая всё объясняет. Халтура, как обычно у Microsoft. Даже такой распространённый язык, как немецкий (где upcase(«ß») == «SS») поддержать нельзя.
Я описал алгоритм NTFS.Вы описали ваши фантазии на тему алгоритма NTFS.
Но, как вы заметили, поздно пить Боржоми, потому что у файлов и так два имени.Совершенно необязательно. Более того, «так хорошо вам известный» «алгоритм NTFS» включает в себя, кроме всего прочего, и вменяемую семантику тоже. Но, разумеется, поведение по умолчанию — это «Мы ♥ троянов. Разводите наших троянов».
Ну не выйдет просто так сравнить строки.Почему не выйдет? Выйдет. Было бы желание. Два ключа в реестре, небольшой хак в системную библиотеку — и ваш Git (равно как и все остальные программы, использующие FILE_FLAG_POSIX_SEMANTICS) в безопасности. И незачем морочить людям голову.
Вы к какой-то неспортивной ковровой бомбардировке вперемешку с эмоциями перешли, так что я воздержусь от продолжения спора, пожалуй. Тем более, что до профиля уже кто-то добрался. Да и ваше мнение вполне имеет право на существование. Скажем, мне регистрозависимость файловой системы была бы строго параллельна, если бы везде в гуе можно было имитировать регистронезависимость.
Да и для большинства приложений сравнивать имена файлов не очень-то нужно. Открываешь файл с нужным флагом — и ось сама разберётся: заменить, переписать, добавить.
Так, в довесок: вам известно много уязвимостей из-за регистра? А то, как я понял из статьи, на гитхабе дырой никто не пользовался, то есть уязвимость осталась преимущественно теоретической.
Да и для большинства приложений сравнивать имена файлов не очень-то нужно. Открываешь файл с нужным флагом — и ось сама разберётся: заменить, переписать, добавить.
Так, в довесок: вам известно много уязвимостей из-за регистра? А то, как я понял из статьи, на гитхабе дырой никто не пользовался, то есть уязвимость осталась преимущественно теоретической.
Открываешь файл с нужным флагом — и ось сама разберётся: заменить, переписать, добавить.Вы про обработку многих файлов за раз ничего не слышали? Бывает иногда, да.
Так, в довесок: вам известно много уязвимостей из-за регистра?Ну дык. Почти во всех приложениях, которые пытаются как-то интерпретировать имена файлов. JSP (там целая пачка уязвимостей разной степени стрёмности), ROR, Lighttpd и т.д. и т.п.
Вы про обработку многих файлов за раз ничего не слышали?
Наверное, пока спать ложиться, потому что я не понимаю, как это связано с проверкой имён файлов на равенство.
Если вы обрабатываете один файл, имя для которого пользователь выбирает руками, то вам, действительно, неважно — как он называется. Как только вы начинаете обрабатывать группы файлов у вас немедленно возникают вопросы обработки имён файлов. Вы какие-то файлы обрабатываете особым образом (как в статье, где ".git" имеет особый смысл), или вы пытаетесь реагировать на расширение файла (и из-за того, что разные библиотеки по разному реагируют на расширения написанные в разных регистрах у вас возникают уязвимости), или ещё как-нибудь реагируете на разные имена файлов. В случае «файловой системы с граблями» вас на каждом шагу поджидают проблемы.
Как я уже замечал, файловых систем без грабель, увы, не бывает: в MacOS и Windows это независимость от регистра, а в UNIX — возможность использовать в именах файлов вообще все символы, включая возврат каретки, двоеточие, управляющие последовательности и прочее. И первый вариант и второй кончаются слезьми. MacOS, как обычно, переплюнула всех: она позволяет создавать проблемы обоих видов.
Как я уже замечал, файловых систем без грабель, увы, не бывает: в MacOS и Windows это независимость от регистра, а в UNIX — возможность использовать в именах файлов вообще все символы, включая возврат каретки, двоеточие, управляющие последовательности и прочее. И первый вариант и второй кончаются слезьми. MacOS, как обычно, переплюнула всех: она позволяет создавать проблемы обоих видов.
Почему независимость от регистра «кончаются слезьми»?
Все счастливые семьи одинаковы, а каждая несчастливая несчастлива по своему. Не существует какой-то абстрактной «независимости от регистра». Про «ß» я уже писал. Но даже если вы возьмете самую что ни есть «скалу»: ASCII. Для символа «I» вы с удивлением обнаружите надпись «Turkish and Azerbaijani use U+0131 for uppercase» (ну а для «i» будет написано «Turkish and Azerbaijani use U+0130 for uppercase»). А, промежду прочим, символ «i» как-раз-таки и используется в названии каталога «.git».
Ну а дальше всё просто: если в одном месте у вас одна «независимость от регистра», а в другом — другая «независимость от регистра», то как бы ни старались разработчики, а что-нибудь где-нибудь да сработает не так.
В мире, где существует только US-ASCII «независимость от регистра» ещё как-то работала, в мире, где существуют другие языки она не работает никак. Причём, что характерно, как раз большинство пользователей «не отличающих» слов «Вера» и «вера» (и ради которых, теоретически, весь сыр-бор затеяли) категорически не согласны использовать только и исключительно «faith»-пусть даже им разрешат его писать как «FaItH».
Ну а дальше всё просто: если в одном месте у вас одна «независимость от регистра», а в другом — другая «независимость от регистра», то как бы ни старались разработчики, а что-нибудь где-нибудь да сработает не так.
В мире, где существует только US-ASCII «независимость от регистра» ещё как-то работала, в мире, где существуют другие языки она не работает никак. Причём, что характерно, как раз большинство пользователей «не отличающих» слов «Вера» и «вера» (и ради которых, теоретически, весь сыр-бор затеяли) категорически не согласны использовать только и исключительно «faith»-пусть даже им разрешат его писать как «FaItH».
Про «ß» я уже писал.
А эссет есть на клавиатуре?
Для символа «I» вы с удивлением обнаружите надпись «Turkish and Azerbaijani use U+0131 for uppercase» (ну а для «i» будет написано «Turkish and Azerbaijani use U+0130 for uppercase»). А, промежду прочим, символ «i» как-раз-таки и используется в названии каталога «.git».
Т.е. разные языки используют разные uppercase'ы для «тех же» символов. И? Как это влияет на сравнение двух строк с учетом codepage'а?
Причём, что характерно, как раз большинство пользователей «не отличающих» слов «Вера» и «вера» (и ради которых, теоретически, весь сыр-бор затеяли) категорически не согласны использовать только и исключительно «faith»-пусть даже им разрешат его писать как «FaItH».
Извините, я не понял сути аргумента — эти пользователи не хотят использовать исключительно латиницу, и хотят регистронезависимость в другом языке. Почему это «не работает»? Если мы знаем, какой язык используется? И — насчет затеяли — регистронезависимость файлов в той же винде не затеяна, ей сто лет в обед.
Т.е. разные языки используют разные uppercase'ы для «тех же» символов. И? Как это влияет на сравнение двух строк с учетом codepage'а?У вас в каталоге затесались
.git и .gİt. Вторая использует ту самую U+0130. Что будете делать? Учтите, что турецкий пользователь должен ожидать, что это одинаковые имена, а все остальные — что разные. В зависимости от того, что система записала в файл $upcase либо те, либо другие останутся с обманутыми ожиданиями. Более того, если кто‐то догадался записать, что toupper('i') == 'İ' (и так же для всех остальных латинских букв, имеющих свой верхний регистр в турецком языке) в $upcase, то регистронезависимое сравнение имён файлов, написанных на английском, сломается. А если нет, то сломается сравнение на турецком в данной ФС. Или вы ожидаете, что у пользователя из Турции нет ни одного файла с именем на английском языке? Можно нагородить костылей вроде toupper('İ') == 'I' && toupper('i') == 'I', но я абсолютно уверен что более опытные товарищи смогут найти пример, который не решается с помощью таких костылей в принципе.Вы можете сделать корректное с точки зрения компьютера регистронезависимое сравнение. Можете даже сделать его переносимым между системами. Но корректное с точки зрения пользователя сравнение невозможно в принципе, потому что имена файлов не имеют свойства «язык», введение с ручным контролем пользователя этого пользователя отвратит, автоматическое проставление языка не всегда корректно и весьма ресурсозатратно, и в любом случае вместо одной кодовой страницы вы получите целую тучу, к тому же станет совершенно не понятно, как нормализовывать имя файла, если в каталоге есть файлы с разной кодовой таблицей.
Согласен, при доступе разных пользователей (в смысле, с разными языками) к одному ресурсу все гладко не получится, ".git" и ".гит" не одно и то же, как ни крути.
Сдается мне, что в таком случае надо договариваться об использовании строго ASCII. Ибо если стоит задача обеспечить одинаковый, однородный доступ всем, независимо от их языков, надо использовать что-то третье, что всеми понимается одинаково.
Я для себя давно принял это правило — при переносе между системами, втч между разными странами, использовать исключительно имена латиницей. Как раз чтобы не было никакой неразберихи ни с кодировками, ни с восприятием «а у нас так».
Но, с другой стороны, если это не внешний репозиторий, а просто локальный файл. Что плохого, если система позволяет запустить «mplayer „фильм1.скачано отсюда.divx“» вместо «MPlayer „Фильм1.Скачано Отсюда.DivX“» с учетом текущей локали?
Сдается мне, что в таком случае надо договариваться об использовании строго ASCII. Ибо если стоит задача обеспечить одинаковый, однородный доступ всем, независимо от их языков, надо использовать что-то третье, что всеми понимается одинаково.
Я для себя давно принял это правило — при переносе между системами, втч между разными странами, использовать исключительно имена латиницей. Как раз чтобы не было никакой неразберихи ни с кодировками, ни с восприятием «а у нас так».
Но, с другой стороны, если это не внешний репозиторий, а просто локальный файл. Что плохого, если система позволяет запустить «mplayer „фильм1.скачано отсюда.divx“» вместо «MPlayer „Фильм1.Скачано Отсюда.DivX“» с учетом текущей локали?
Но, с другой стороны, если это не внешний репозиторий, а просто локальный файл. Что плохого, если система позволяет запустить «mplayer „фильм1.скачано отсюда.divx“» вместо «MPlayer „Фильм1.Скачано Отсюда.DivX“» с учетом текущей локали?Давайте вы расскажете, как вы видите практическое воплощение вашего запроса, а я скажу, почему так делать не надо. Автодополнение можно, нужно и уже научили игнорировать регистр, если пользователь не против. Можно сделать такое же автодополнение в диалоге открытия файлов. Но попытка сделать что‐то подобное в системной функции открытия файла обязательно приведёт как минимум к коллизиям имён: у нас есть два файла
input.tXt и input.TxT. Какой надо открыть, если у нас спросили input.txt (почему ФС не должна быть регистронезависимой уже обсудили, поэтому считаем, что она регистрозависимая и существование таких файлов возможно)? Можно нагородить кучу условий для обхода таких ловушек в такой функции, но из‐за их существования с регистрозависимой ФС регистронезависимая функция открытия файлов непременно будет тормозить.
А эссет есть на клавиатуре?
На всех продаваемых в Германии, Австрии и частично в Швейцарии есть. А также и умляуты: Ö, Ä, Ü.
Ну, \0 все-таки относительно сложно использовать в имени файла.
То есть, приведение к верхнему регистру работает в общем случае некорректно, сравнение некорректно в принципе (две разных строки вполне могут приводиться к одинаковой строке в верхнем регистре), поддержка новых языков в принципе невозможна (иначе вместо «инвариантной» локали образуется целый набор локалей, зависящий от версии ОС), от гиганских таблиц (представляющих собой локаль) так и не избавились и реализация работает медленнее регистрозависимой.
Ну и оказывается, что вместо инвариантной локали всё-таки используется локаль, встроенная в файловую систему. Просто блеск! Теперь количество гиганских таблиц равно количеству файловых систем.
Ну и оказывается, что вместо инвариантной локали всё-таки используется локаль, встроенная в файловую систему. Просто блеск! Теперь количество гиганских таблиц равно количеству файловых систем.
Спасибо за комментарий, получается, что единственная проблема — это неоднозначный case mapping в разных языках. Интересно, как её решили в Microsoft и Apple.
Подробнее и зануднее
Соблюдение соглашений по именованию файлов — это задача решается либо административно: объяснить всем правила, за нарушения наказывать, либо инженерно: написать precommit-hook, который будет либо отклонять, либо автоматически переименовывать файлы.
Про юникод я думал, но получается, что проблема с нормализацией юникода — это всё та же проблема экономии процессорного времени и оперативной памяти. Проблема сложная, но решаемая.
Процессорное время и оперативная память дешевеют день ото дня, в отличие от человеческого времени, так что логично переложить проблему с людей на машины.
в проекте внезапно не будет бардака вида:Не совсем понимаю, как бардак с именованием файлов связан с или может быть устранён регистрозависимой файловой системой.
— qwindowtext.cpp
— qWindowText.h
— QtSocketHandler.cpp
— QTSocketWritehandler.cpp
— qtSocketReadHandler.cpp
— qtsocketaccess.h
Соблюдение соглашений по именованию файлов — это задача решается либо административно: объяснить всем правила, за нарушения наказывать, либо инженерно: написать precommit-hook, который будет либо отклонять, либо автоматически переименовывать файлы.
Про юникод я думал, но получается, что проблема с нормализацией юникода — это всё та же проблема экономии процессорного времени и оперативной памяти. Проблема сложная, но решаемая.
Процессорное время и оперативная память дешевеют день ото дня, в отличие от человеческого времени, так что логично переложить проблему с людей на машины.
Внезапно, коллейшен часто зависит не только от кодировки, а еще и от языка и локали (например, с точки зрения немецкого «Mael» = «mäl», а с точки зрения татарского — это два совершенно разных слова).Это не совсем так. В немецком языке "ä" не равно «ae», «ae» — это допустимая транслитерация символа "ä" (примерно как в русском используют «е» вместо «ё» или иногда апостроф вместо твёрдого знака — «под'ём» — вас скорее всего поймут правильно, но это же не одно и то же), которой пользуются в основном, когда использовать умляуты нет возможности (в международных адресах, билетах, визах и т.п., чтобы не смущать людей и программное обеспечение на той стороне) или нет желания (лень переключать раскладку, не нашёл умляут в айфоне), но «ae» встречается и как самостоятельное буквосочетание в немецком языке, не означающее и не читающееся как "ä" (Aerodynamik != Ärodynamik, Rafael != Rafäl).
Завтра какой-то редкий мировой язык с 20 тысячами носителей заявит, скажем, что у него «i» = «aex», и, внезапно, ".git" можно будет записать, как ".gaext" в этой локали.Да, в турецком ".gıt" = ".GIT" и ".GIT" != ".git".
1. Если коротко — то наличие возможности провоцирует, ей начинают пользоваться. Административные запреты где-то сработают, где-то — нет. В итоге в проекте будет 3-4% хорошо запрятанного бардака. Технические запреты, кроме всего прочего, (а) озлобляют людей на пустом месте, (б) не так уж просто реализуемы и на клиенте, и на сервере, (в) де факто означают, что у нас все-таки case sensitive файловая система хотя бы на сервере VCS — не важно, реализованная за счет файловой системы или за счет того, что VCS не принимает файлы не в том регистре.
Гораздо проще жить в ситуации, скажем, когда по умолчанию используемая всеми сборочная система настолько строга, что попытка поместить класс MyClass файл myClass.java, скажем, приводит к фатальной ошибке сборки — т.е. де факто иметь регистрозависимую ФС на клиентах.
2. Про умляуты — к сожалению, я немецкий знаю плохо, но вот, например, вполне реально существующий MySQL, который считает, что «ae» = "ä":
Собственно, исходный посыл был только в том, что независимость от регистра сильно зависит от локали.
Гораздо проще жить в ситуации, скажем, когда по умолчанию используемая всеми сборочная система настолько строга, что попытка поместить класс MyClass файл myClass.java, скажем, приводит к фатальной ошибке сборки — т.е. де факто иметь регистрозависимую ФС на клиентах.
2. Про умляуты — к сожалению, я немецкий знаю плохо, но вот, например, вполне реально существующий MySQL, который считает, что «ae» = "ä":
Унылые подробности
И, да, к сожалению, приведенные вами контрпримеры, там тоже работают:
mysql> SET collation_connection = latin1_german2_ci; Query OK, 0 rows affected (0.00 sec) mysql> SELECT 'Mäl' = 'mael'; +-----------------+ | 'Mäl' = 'mael' | +-----------------+ | 1 | +-----------------+
И, да, к сожалению, приведенные вами контрпримеры, там тоже работают:
mysql> SELECT 'aerodynamik' = 'ärodynamik'; +-------------------------------+ | 'aerodynamik' = 'ärodynamik' | +-------------------------------+ | 1 | +-------------------------------+
Собственно, исходный посыл был только в том, что независимость от регистра сильно зависит от локали.
Про почтовые аккаунта вам уже сказали.
А касательно вот этого:
Нежелание использовать мозг всегда приводит к проблемам.
Затем, что это удобно. Удобно, например, иметь файл «Smth» и папку «smth» с частями этого самого Smth. Удобно в поиске искать file* и не находить File* и т.д.
Я не знаю как окружающие, наверное, все это индивидуально, но лично я, каждый раз как приходится работать с регистронезависимыми ФС испытываю «боль и унижение» :)
А касательно вот этого:
Но как только в дело вступает пользователь, мы получаем опять проблемы и путаницу — для многих файлы «my work document.doc» и «My work document.doc» — это одно и то же, ровно как и bart simpson и Bart simpson — это одно и то же имя.
Нежелание использовать мозг всегда приводит к проблемам.
Но зачем сегодня иметь возможность различать файлы file.txt и File.txt
Затем, что это удобно. Удобно, например, иметь файл «Smth» и папку «smth» с частями этого самого Smth. Удобно в поиске искать file* и не находить File* и т.д.
Я не знаю как окружающие, наверное, все это индивидуально, но лично я, каждый раз как приходится работать с регистронезависимыми ФС испытываю «боль и унижение» :)
Нежелание использовать мозг всегда приводит к проблемамЭто не аргумент. Не всегда его нужно использовать. Человек не использует мозг, когда в этом нет необходимости. Есть такое выражение «Сделать на автомате». Вы же явно не используете мозг когда ходите, давно катаетесь на велосипеде или на горных лыжах и т. п.
Что касается поиска, то обычно есть такая волшебная опция «искать с учётом регистра». :)
Это не аргумент
Это, действительно, не аргумент. Это факт :)
Есть такое выражение «Сделать на автомате»
Есть. Суть его в использовании мозгом шаблонов. Если человек «на автомате» будет полагать, что регистр букв важен, он будет поступать соответствующим образом. Причем, различие регистра для человека естественно. Обычно, человек понимает, что «вера», этот вероисповедание, а «Вера» — его грудастая соседка, «то» — союз, а «ТО» — какая-то аббревиатура, скорее всего техобслуживание. Так зачем усложнять человеку жизнь неестественным игнорированием регистра букв?
Что касается поиска
Кроме поиска, выше еще несколько примеров было. Я могу еще повспоминать. Но вам оно точно нужно? У вас же только один аргумент есть: «так проще». Причем, для меня это не аргумент, т.к. мне проще с регистрозависимой ФС.
Обычно, человек понимает, что «вера», этот вероисповедание, а «Вера» — его грудастая соседка, «то» — союз, а «ТО» — какая-то аббревиатура, скорее всего техобслуживание. Так зачем усложнять человеку жизнь неестественным игнорированием регистра букв?
А теперь покажите мне людей, которые знают, как правильно писать: Московский Государственный Университет или Московский государственный университет. Да что там: когда надо писать «московский», а когда «Московский». Приведите единое правило написания заголовков, с которым все согласятся: HOW TO TRAIN YOUR DRAGON, How To Train Your Dragon, How to Train Your Dragon, How to train your dragon. Мне продолжать?
Прежде чем вы начнёте уверять меня в стопроцентной грамотности всего населения планеты Земля, должен отметить, что у вас с десяток неправильных знаков пунктуации на пять предложений. Так, для статистики.
Мне продолжать?
Для начала расскажите, какое отношение грамотность, заголовки и прочее имеют к файловой системе? Что мешает юзеру писать с ошибками сейчас?
Прежде чем вы начнёте уверять меня в стопроцентной грамотности всего населения планеты Земля, должен отметить, что у вас с десяток неправильных знаков пунктуации на пять предложений. Так, для статистики.
Это авторская пунктуация. Имею право.
Для начала расскажите, какое отношение грамотность, заголовки и прочее имеют к файловой системе?
Простые смертные (не грамматические нацисты) не настолько внимательно относятся к регистру букв, как к орфографии, например. И дело совершенно не в том, что к этому их приучила файловая система, просто на подобные ошибки многим покласть, они не столь заметны.
И вот когда люди, которым свойственно не заморачиваться насчёт регистра букв, работают с файлами, важность регистра вгоняет их в ступор. Вы не забывайте, что файлы бывают не столько «QtSocketHandler.cpp», но и более приземлённые.
Это авторская пунктуация. Имею право.
Нет. «Обычно, человек понимает, что «вера», этот вероисповедание» — это издевательство над русским языком, которое мешает понимать текст, как ни поверни. Впрочем, если вы сможете аргументировать расстановку знаков, то я весь внимание.
И вот когда люди, которым свойственно не заморачиваться насчёт регистра букв, работают с файлами, важность регистра вгоняет их в ступор. Вы не забывайте, что файлы бывают не столько «QtSocketHandler.cpp», но и более приземлённые.Какая разница, какие у вас файлы? Важно как вы их открываете: выбором из списка или набором имени файла. Если вы их выбираете из списка, то вам, вообще говоря, всё равно — отличает ли файловая система «bart»а от «Bart»а или нет, а если вы вбиваете что-то руками, то это гиблый номер: вы никогда не добьётесь идеала. Почему «bart simpson.txt» и «Bart Simpson.txt» — это одно и то же, а вот «Барт Симпсон.doc» — что-то другое? Не надо даже пытаться имитировать женскую логику, честное слово, вы всё равно проиграете. Регистронезависимость файловых систем — это костыль из 70х, который помогал людям, когда компьютеры были большими, а байты в них — ещё больше и когда имя файла нельзя было выбрать из списка. Давно пора выкинуть эти костыли к бесам, но для этого придётся отказаться от Windows… ну всему своё время.
И не надо говорить, что «вы ничего не понимаете, нормальные люди работают только с Windows»: систем, разливающих регистр в имени файлов сейчас уже больше, чем систем, которые их не различают (Android, однако) и что? Кто-то умер? Да большинство людей, использующих телефоны даже не догадываются о том, что их телефон регистр файлов не отличает (вернее отличает, но не всегда) — и ничего, живут же как-то…
Вы не поверите, но ввод имени файла офигительно работает в диалоге открытия файла в винде. Автодополнение, маски, все дела. (Ещё б текущий фильтр учитывало...) Так вот, там мне регистрозависимость очень сильно мешала бы жить.
Сейчас вы мне ответите, что это забота гуя, а не файловой системы…
А если считать среди систем с (удобной) клавиатурой и систем, за которыми работают (а не только кидают птиц и смотрят котят)? Регистронезависимость удобна тем, кто пользуется клавиатурой. При тачевом интерфейсе — да, регистр пофиг.
Сейчас вы мне ответите, что это забота гуя, а не файловой системы…
систем, разливающих регистр в имени файлов сейчас уже больше, чем систем, которые их не различают (Android, однако) и что?
А если считать среди систем с (удобной) клавиатурой и систем, за которыми работают (а не только кидают птиц и смотрят котят)? Регистронезависимость удобна тем, кто пользуется клавиатурой. При тачевом интерфейсе — да, регистр пофиг.
А если считать среди систем с (удобной) клавиатурой и систем, за которыми работают (а не только кидают птиц и смотрят котят)?Давайте сразу рассмотрим системы с Windows, чего уж там.
Windows люди используют потому, что что под неё куча софта, а вовсе не потому, что в ней есть куча удобных мест для троянописателей (типа той же «регистронезависимой» файловой системы). Одно с другим связано, конечно.
Windows люди используют потому, что что под неё куча софта
И это здорово. Нравится кому-то, или нет — оно вот так, и долго так будет. Холивары бессмысленны, с этим надо жить.
Давайте сразу рассмотрим системы с Windows, чего уж там.
Нет, ну почему. Линукс очень даже активно используется программистами. Если считать по моему критерию, то у линукса будет достойное положение, хотя винда в сумме победит за счёт людей других профессий, конечно.
Не понял, к чему вы кучи софта упомянули. Я не пытался линукс унизить, я хотел продемонстрировать взаимосвязь удобства регистронезависимости с клавиатурой. Кстати о клавиатуре и программистах. При вводе кода автодополнение обычно регистронезависимое даже в регистрозависимых языках. Удобно же.
При вводе кода автодополнение обычно регистронезависимое даже в регистрозависимых языках.Это не так. Скажем, в IntelliJ Idea
fbq даст в автодополнении и fbq, и fizBazQuix, и FizBq. fBQ же дополнится (при тех вариантах в коде) только до fizBazQuix. И это — удобно.Если на «fbq» выдаётся «fizBazQuix» и «FizBq» — это и называется регистронезависимость. :) Причём не знаю, как в Идее, а в Решарпере аналогичное поведение не сразу появилось, раньше была строгая регистрозависимость («fizBazQuix» не выдался бы).
Вообще, тут скорее специальный синтаксис, о регистро(не)зависимости говорить не совсем корректно.
Вообще, тут скорее специальный синтаксис, о регистро(не)зависимости говорить не совсем корректно.
Это регистрозависимое автодополнение, т. к. поведение отличается при разном регистре.
Вообще, тут скорее специальный синтаксис, о регистро(не)зависимости говорить не совсем корректно.
Кстати о клавиатуре и программистах. При вводе кода автодополнение обычно регистронезависимое даже в регистрозависимых языках. Удобно же.Вернулись туда же, откуда начали. В общем, либо крестик…
При вводе кода автодополнение обычно регистронезависимое даже в регистрозависимых языках. Удобно же.Часто можно настроить, если всё же не удобно.
В zsh автодополнение имён файлов тоже может быть регистронезависимым. Реализация регистронезависимости на этом уровне куда как проще и однозначнее регистронезависимости на уровне ФС: здесь вы можете просто взять текущую локаль и никто вас не осудит. Можете взять ту самую гиганскую ICU. В ФС текущую локаль взять нельзя, т.к. она должна быть переносимой между системами. $upcase будет некорректен на машине с произвольной локалью, что бы в этой таблице не содержалось. А запихивание ICU в ядро и применение соответствующих алгоритмов при каждой попытке открыть файл… Есть и более простые способы превратить систему в тормозящее г…но. ICU хороша, но там где она есть и применяемая к чему надо, а не в ядре и применяемая ко всему подряд.
Это, действительно, не аргумент. Это факт :)
Сентенция вида «если пользователь не отличает Document1 и document1, то он просто не пользуется мозгом» — просто вброс на вентилятор. Не аргумент и не факт.
«и ̆» и «Й» это одно и то же?
Удобно, например, иметь файл «Smth» и папку «smth» с частями этого самого Smth.Удобно стрелять себе в ногу.
Мне, например, удобно хранить части (метаданные) файла «smth» не в папке «Smth» или «smth_files», а в resource fork-е файла «smth». В NTFS для этого существует ADS (альтернативные потоки).
Там можно хранить всевозможные атрибуты файла, тэги, историю изменений, уменьшенную версию для изображений и документов, тип файла (вместо расширения) и т.п.
Но все эти клёвые удобные штуки поддерживаются только в родных ФС, так что лучше их не использовать, чтобы случайно не выстрелить себе в ногу.
А зачем в Windows бэкслешем вместо слешей в файловой системе? Ведь в HTTP слеши.
Потому что всюду лошади.
Слеши в файловой системе Windows нельзя использовать из-за того, что DEC использовал их для указания опций в программе PIP для PDP-6. Откуда программа PIP перебралась на RTS/E и далее в CP/M, откуда в MS/DOS пришла команда copy, что немедленно скопировали разработчики разного софта и из-за чего каталоги пришлось разделять бекслешами. Всё просто.
А HTTP как бы не в 1963м появился, он на PIP ну никак повлиять не мог. Тут скорее вопрос: а почему в UNIX каталоги слешами разделяются, а не бекслешами задавать нужно (UNIX ведь тоже разрабатывался на системе со славным PIPом). Решение же, использованное в UNIX (использовать для опций тире не запретив при этом создавать файлы, начинающиеся с тире) выпило гораздо больше крови у всех, чем подход Microsoft с ипользованием бекслеша. Почти столько же, сколько решение Microsoft'а разрешить и даже поощрить использование пробела в имена файлов в Windows 95 или попытки состряпать файловую систему, которая, с одной стороны, хранит разницу между большими и маленькими буквами, а с другой, вроде как её же и не замечает. Никто не идеален, увы.
Слеши в файловой системе Windows нельзя использовать из-за того, что DEC использовал их для указания опций в программе PIP для PDP-6. Откуда программа PIP перебралась на RTS/E и далее в CP/M, откуда в MS/DOS пришла команда copy, что немедленно скопировали разработчики разного софта и из-за чего каталоги пришлось разделять бекслешами. Всё просто.
А HTTP как бы не в 1963м появился, он на PIP ну никак повлиять не мог. Тут скорее вопрос: а почему в UNIX каталоги слешами разделяются, а не бекслешами задавать нужно (UNIX ведь тоже разрабатывался на системе со славным PIPом). Решение же, использованное в UNIX (использовать для опций тире не запретив при этом создавать файлы, начинающиеся с тире) выпило гораздо больше крови у всех, чем подход Microsoft с ипользованием бекслеша. Почти столько же, сколько решение Microsoft'а разрешить и даже поощрить использование пробела в имена файлов в Windows 95 или попытки состряпать файловую систему, которая, с одной стороны, хранит разницу между большими и маленькими буквами, а с другой, вроде как её же и не замечает. Никто не идеален, увы.
Тут надо ещё заметить, что винда позволяет использовать в качестве разделителей и прямые, и обратные слэши. Можно хоть
C:\\Windows//notepad.exe написать — винда поймёт.Поймёт, но не везде и не всегда. Microsoft ещё в MS-DOS 2.0 предусмотрел опцию, позволявшую использовать "-" вместо "/" для опций, но так с тех пор на прямые слеши и не перешёл. Где-то работает, где-то — не работает, всюду разброд и шатание.
Хорошо хотя бы то, что в именах файлов нельзя и использовать слеши — ни прямые, ни обратные.
Хорошо хотя бы то, что в именах файлов нельзя и использовать слеши — ни прямые, ни обратные.
Можете привести примеры, где прямые слеши не работают? Просто где пытался — нигде с проблемами не сталкивался. Правда я программист, а не сисадмин, поэтому файлы и скрипты не так активно мучаю.
PIP
Очень, кстати, мощная программка была. Можно было копировать с разделением на блоки, выставлением прав/даты создания. Дописывание в конец. Учитывалась версия файла (мулька файловой системы RSX, что-то типа ADS в NT, только работает автоматически). ls тоже через PIP делался. Создание каталога, удаление каталога тоже.
Вы знаете, «регистронезависимость» отлично работает для простых языков, в которых нет композитного юникода с акцедентами и направлением ввода.
Вот, например, в рамках «case insensitive», «Й» и «И ̆» («и» с последющим символом крышки) — это одно и тоже или нет? В случае case sensitive системы очевидно — «если оно написано иначе, значит другой файл». Даже если выглядит одинаково. А вот ваш аргумент тут начинает дырявиться, потому что «Й» и «й» это одно и то же, а «й» «и ̆» — уже нет.
А как только вы соглашаетесь на нормализацию символов в полный рост, то тут же во-первых подтягиваются всякие хинду и прочие, а во-вторых злые хаккеры начинают вам направление чтения текста менять и всячески «ехе» маскировать.
Вот, например, в рамках «case insensitive», «Й» и «И ̆» («и» с последющим символом крышки) — это одно и тоже или нет? В случае case sensitive системы очевидно — «если оно написано иначе, значит другой файл». Даже если выглядит одинаково. А вот ваш аргумент тут начинает дырявиться, потому что «Й» и «й» это одно и то же, а «й» «и ̆» — уже нет.
А как только вы соглашаетесь на нормализацию символов в полный рост, то тут же во-первых подтягиваются всякие хинду и прочие, а во-вторых злые хаккеры начинают вам направление чтения текста менять и всячески «ехе» маскировать.
Вот, например, в рамках «case insensitive», «Й» и «И ̆» («и» с последющим символом крышки) — это одно и тоже или нет?Очевидно, что нет. Оно и выглядит не одинаково :)
А как только вы соглашаетесь на нормализацию символов в полный рост, то тут же во-первых подтягиваются всякие хинду и прочие, а во-вторых злые хаккеры начинают вам направление чтения текста менять и всячески «ехе» маскировать.Ну, маскировать файлы можно и без юникода — ФС в linux позволяют использовать все символы кроме слэша.
У вас криво рендерится. А вообще, это просто денормализованная форма той же графемы. Не «похожие символы», а буквально (в виде двух символов юникода) записанное «и краткое».
И я спрашиваю не про «маскировку», а про признание их одинаковыми с заглавными символами. Формально — это один и тот же символ, значит, регистронезависимое должно их считать одним и тем же. Однако…
Юниксовый подход, когда имя — это просто набор литералов без интерпретации со стороны файловой системы (файловой системы! чтобы она при этом хорошо в юникодах разбиралась?) — куда более простой и работающий «без дыр» (наподобие примера выше).
И я спрашиваю не про «маскировку», а про признание их одинаковыми с заглавными символами. Формально — это один и тот же символ, значит, регистронезависимое должно их считать одним и тем же. Однако…
Юниксовый подход, когда имя — это просто набор литералов без интерпретации со стороны файловой системы (файловой системы! чтобы она при этом хорошо в юникодах разбиралась?) — куда более простой и работающий «без дыр» (наподобие примера выше).
OS X может работать на регистрозависимой файловой системе (по дефолту устанавливается регистронезависимая), однако некоторые программы начинают работать с ошибками. Поэтому лучшим решением для OS X является создание отдельного раздела под все пользовательские данные с регистрозависимой версией файловой системы.
Макось регистронезависима.
Не легче ли разворачивать в полный путь и определять стоит ли писать в эту папку. Просто так все хаки надо предсказывать.
Богатым на баги выдался год. Git под занавес тоже отличился.
Видимо, git окончательно победил mercurial. Баг был обнаружен сначала в mercurial, потом авторы mercurial нашли этот баг в git. Теперь в новостях везде «баг в git»; тут, например, даже упоминания hg нет.
Я лично с hg-проектами сталкивался два раза. Почаще попадались SVN и CVS. Все остальное — git.
В рассылке как раз есть пара строк про mercurial land:
Имхо — удобнее, когда одна из программ станет стандартом де-факто, хотя бы в какой-то области: не будут постоянно путаться команды (что не отменяет необходимость конкуренции между разными системами)
В рассылке как раз есть пара строк про mercurial land:
A big «thanks!» for bringing this issue to us goes to our friends in
the Mercurial land, namely, Matt Mackall and Augie Fackler.
Имхо — удобнее, когда одна из программ станет стандартом де-факто, хотя бы в какой-то области: не будут постоянно путаться команды (что не отменяет необходимость конкуренции между разными системами)
Имхо — удобнее, когда одна из программ станет стандартом де-фактоWindows, например? :)
И тут есть один тонкий неловкий момент: git под windows появился далеко не сразу.
Скорее, Photoshop в обработке изображений или Apache (в свое время), nginx (сейчас) в роли сервера
Что нисколько не умаляет заслуг GIMP и пр:)
Что нисколько не умаляет заслуг GIMP и пр:)
Nginx не является стандартом де-факто. Может, в России так и есть, но не в мире.
Еще нет, но во всех новых инструкциях/статьях, новых технологиях его часто ставят на фронтенд. Сайты из топ-100 единогласно предпочитали nginx еще год назад. И да, в России, в Украине, в Беларуси — за ним 2/3 рынка.
Преобладание Апача — ИМХО, дань традициям (он по умолчанию включен во многие дистрибутивы), привычкам, легкости настройки / большему количеству мануалов, плюс еще множество админов, умеющих правильно его готовить. Ну а главное — на малонагруженных страничках разница с nginx не сильно заметна. Когда проект вырастает, то сразу выделяют фронтенд и бекенд (если изначально этого не сделали).
Всё верно. Поэтому я и написал, что «не является».
Ещё добавлю из личных наблюдений: когда на зарубежных конференциях произносится слово «nginx», большая часть слушателей искренне не понимают, что это и зачем, если есть apache. А многие так вообще про nginx не слышали.
Ситуация меняется, да, и это хорошо, но, справедливости ради, всё-таки nginx — пока ещё не стандарт де-факто.
Ещё добавлю из личных наблюдений: когда на зарубежных конференциях произносится слово «nginx», большая часть слушателей искренне не понимают, что это и зачем, если есть apache. А многие так вообще про nginx не слышали.
Ситуация меняется, да, и это хорошо, но, справедливости ради, всё-таки nginx — пока ещё не стандарт де-факто.
Сабжевая уязвимость это конечно плохо. В то же время, в репозиториях часто можно найти Makefile или иную инструкцию для сборки — а это тоже возможность выполнения произвольного кода (можно использовать команды ОС или даже скомпилировать что-то свое — возможности безграничны).
Как часто вы пользуетесь chroot для сборки проектов?
Как часто вы пользуетесь chroot для сборки проектов?
Забавно. У меня со вчерашнего дня Avast стал запускать git в песочнице.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Уязвимость в Git: выполнение произвольных команд