Comments 62
Как я понял, AFS появится не в Sierra (по крайней мере, не для конечных потребителей), а в следующей версии, в 2017ом. И еще многие вещи до сих пор пока не работают: TimeMachine, FusionDrive, FileVault, её нельзя использовать для startup дисков и прочее.
Так что все еще сырое и в разработке, но все таки очень приятно знать, что в apple не только над новыми смайликами трудятся.
Так что все еще сырое и в разработке, но все таки очень приятно знать, что в apple не только над новыми смайликами трудятся.
не получилось бы как с ReFS когда один резет превращает весь раздел в тыкву.
у… поддержка регистрозависимых имен файлов… ((
Зачем?
Что бы жизнь мёдом не казалась.
Надо отметить, что регистронезависимое сравнение, строго говоря, зависит от локали.
Например, в Турции: UPPER("windows") = "WİNDOWS", а не "WINDOWS", как в большей части света.
Очень занимательно посмотреть, какие символы считаются одинаковыми при регистронезависимом сравнении в MySQL: http://collation-charts.org/mysql60/mysql604.utf8_general_ci.european.html
А то что основная масса FS регистрозависимые, вас не смущает? В быту регистронезависимые имена файлов доставляют не мало проблем, по краней мере для меня.
Ага. регистрозависимые имена файлов — вот восторг!
file1.txt (l — мелкая L)
fiIe1.txt (I — заглавная i)
file1.txt (l — мелкая L)
fiIe1.txt (I — заглавная i)
продолжу жаловаться.
Пользователи присылают мне в ПО(робот) файлы по электронной почте. Файлы наименованы: OMSK.xls, Ufa.xls, Moscow.xls
Пользователи именуют файлы не обращая внимания на регистр. Т.е. сегодня может быть OMSK.XLS, завтра Omsk.xls, послезавтра omsk.xls
Может я неправ, конечно, но регистронезависимая ФС избавляет меня от операции приведения имен файлов к единому регистру и облегчает отладку\работу
В чем смысл регистрозависимой фс — не могу понять, ну честно. Только в том, что в именах файлов можно использовать camelStyle?
textFile1.txt и TextFile1.txt
Пользователи присылают мне в ПО(робот) файлы по электронной почте. Файлы наименованы: OMSK.xls, Ufa.xls, Moscow.xls
Пользователи именуют файлы не обращая внимания на регистр. Т.е. сегодня может быть OMSK.XLS, завтра Omsk.xls, послезавтра omsk.xls
Может я неправ, конечно, но регистронезависимая ФС избавляет меня от операции приведения имен файлов к единому регистру и облегчает отладку\работу
В чем смысл регистрозависимой фс — не могу понять, ну честно. Только в том, что в именах файлов можно использовать camelStyle?
textFile1.txt и TextFile1.txt
Пользователи просто из-под винды шлют файлы. А NTFS — одна из немногих ФС с такой фигней. Я как-то привык уже на EXT4 к регистрозависимости. Хотя явных плюсов того или другого подхода привести не могу.
Нужна веская причина для усложнения UX того или иного продукта. Иными словами — бритва окамма. Для меня, как программиста, до сих пор большим вопросом является регистро-зависимый синтаксис С. Хорошо что IDE помогают в этом, и тут даже появляются некоторые плюсы, но в целом? Я подозреваю что это было изначально сделано, чтобы парсерам было прощще, а потом все просто привыкли к этому. Итого вопрос — зачем создают сложности, там где их можно избежать? Мне в spotlight теперь придётся искать файл с учётом заглавных букв?
в спотлайте будет бардак… так что — именно так… ((
В идеале то, как сделано в MacOX сейчас, как мне кажется
— представление файла (в его паспорте) — регистрозависимое, представление в фс — регистроНЕзависимое.
В итоге — пользователю легко именовать файлы так, как ему вздумается, и разработчику — легко их искать.
Примерно так:
bash-3.2$ cd
bash-3.2$ touch file1.txt
bash-3.2$ touch fiIe1.txt
bash-3.2$ touch fiLe1.txt
bash-3.2$ ls -l fi*.txt
-rw-r--r-- 1 alexandre staff 0 14 июн 17:40 fiIe1.txt
-rw-r--r-- 1 alexandre staff 0 14 июн 17:40 file1.txt
bash-3.2$ cat fiie1.txt
bash-3.2$ echo sample > fiie1.txt
bash-3.2$ cat fiie1.txt
sample
bash-3.2$ cat fiIe1.txt
sample
bash-3.2$ uname -a
Darwin MacBook-Pro.local 15.6.0 Darwin Kernel Version 15.6.0: Tue May 17 20:05:28 PDT 2016;
В идеале то, как сделано в MacOX сейчас, как мне кажется
— представление файла (в его паспорте) — регистрозависимое, представление в фс — регистроНЕзависимое.
В итоге — пользователю легко именовать файлы так, как ему вздумается, и разработчику — легко их искать.
Примерно так:
bash-3.2$ cd
bash-3.2$ touch file1.txt
bash-3.2$ touch fiIe1.txt
bash-3.2$ touch fiLe1.txt
bash-3.2$ ls -l fi*.txt
-rw-r--r-- 1 alexandre staff 0 14 июн 17:40 fiIe1.txt
-rw-r--r-- 1 alexandre staff 0 14 июн 17:40 file1.txt
bash-3.2$ cat fiie1.txt
bash-3.2$ echo sample > fiie1.txt
bash-3.2$ cat fiie1.txt
sample
bash-3.2$ cat fiIe1.txt
sample
bash-3.2$ uname -a
Darwin MacBook-Pro.local 15.6.0 Darwin Kernel Version 15.6.0: Tue May 17 20:05:28 PDT 2016;
> Для меня, как программиста, до сих пор большим вопросом является регистро-зависимый синтаксис С.
Регистрозависимый синтаксис в ЯП — однозначное благо, он защищает нормальных людей от говнокодеров, которые пишут кАк иМ НРавиТсЯ. Говорю как человек, довольно долго поддерживавший коммерческое ПО, написанное на паскале, у которого синтаксис регистронезависимый.
Регистрозависимый синтаксис в ЯП — однозначное благо, он защищает нормальных людей от говнокодеров, которые пишут кАк иМ НРавиТсЯ. Говорю как человек, довольно долго поддерживавший коммерческое ПО, написанное на паскале, у которого синтаксис регистронезависимый.
а что, на маках давно по-умолчанию она регистрозавсимая? сколько себя помню, всегда были проблемы с тем, что не так файл из кода ищещь и на симуляторе все ок, а не iPhone нет ресурса.
Не знаю как сейчас, но когда-то тоже сталкивался с проблемой регистрозависимости, когда прогал под айпад.
В симуляторе пофигу, а на айпаде регистрозависимость, хотя файловая система вроде одна.
Стало интересно, полез в управление разделами в маке
И там при форматировании был параметр регистрозависимость, по умолчанию выключен.
Скорей всего до сих пор так, только проверить не могу — на рабочем маке админские права не дают
В симуляторе пофигу, а на айпаде регистрозависимость, хотя файловая система вроде одна.
Стало интересно, полез в управление разделами в маке
И там при форматировании был параметр регистрозависимость, по умолчанию выключен.
Скорей всего до сих пор так, только проверить не могу — на рабочем маке админские права не дают
На самом деле, это не NTFS регистронезависимая, это винда регистронезависимая по традиции. Если для винды сделать драйвер любой другой ФС — то ее тома будут вести себя точно так же. В противном случае существующие программы могут перестать работать, и это будет ошибкой.
PS FILE_FLAG_POSIX_SEMANTICS дает поведение "как в *NIX" — к примеру, можно создать два файла, отличающиеся только регистром символов.
UFO just landed and posted this here
Справедливости ради — это два совершенно разных символа и в то же время буква в разных регистрах. Избыточные возможности тоже не всегда хорошо, хотя в данном случае думаю все доводы будут достаточно субъективными. Говоря за себя, я понятия не имею регистрозависима ли винда с NTFS или нет, хотя работаю только в ней сколько себя помню. Так ли это важно на самом деле?
Именно!
Если я захочу так назвать свои файлы — то фс не должна мне мешать. (про целесообразность не будем рассуждать)
Если я захочу так назвать свои файлы — то фс не должна мне мешать. (про целесообразность не будем рассуждать)
Если я не хочу иметь возможность так ошибиться — фс не должна давать мне такой возможности.
Предлагаете на уровне ОС запретить шрифты, в которых разные символы могут быть похожи друг на друга?
При чём здесь шрифты?
Проблема, описанная в комментарии выше по ветке заключается в том, что два разных символа выглядят одинаково в том шрифте, которым отображается тот комментарий. Ниже alexws54tk привёл пример другого шрифта, в котором подобные символы легко различимы. Ему, кстати, необязательно быть моноширинным.
Шрифтопроблемы.
Как сказал оратор выше, это «Шрифтопроблемы». ИМХО, в терминале должен стоять свой любимый
И проблема исчезла.
Моноширинный Шрифт.% touch file1.txt
% touch fiIe1.txt
% touch fiLe1.txt
% ls -l fi*.txt
-rw-r--r-- 1 alex alex 0 июн 14 19:45 fiIe1.txt
-rw-r--r-- 1 alex alex 0 июн 14 19:45 fiLe1.txt
-rw-r--r-- 1 alex alex 0 июн 14 19:44 file1.txt
И проблема исчезла.
UFO just landed and posted this here
Ваш пример не имеет никакого отношения к ригистру.
В основном регистронезависимые имена в файловый системах — это потеря производительность. Ведь если регистр учитывается, то можно просто сравнить байты, а если нет — сначала раскодировать символ(например Ć в unicode U+0106), потом сменить регистр(на ć), и только потом начинать сравнение. К слову, перекодировка нетривиальная задача. Причем это надо сделать 2 раза — для искомого и для всех «зарегистрированных» вариантов(существующих файлов, директорий, и т.д.) на пути. Кроме того тут присутствует не только чтение из памяти, но и запись в нее.
В итого это большой расход памяти, нагрузка на кэш процессора и на шину данных памяти. Если Вы посмотрите сколько сравнений приходится делать FS для того чтоб открыть file.txt, то сразу станет понятно что к чему.
Ну и есть, конечно, эстетический аспект. Я бы возмутился, если бы ко мне обращался человек как к NiAmStEr.
В основном регистронезависимые имена в файловый системах — это потеря производительность. Ведь если регистр учитывается, то можно просто сравнить байты, а если нет — сначала раскодировать символ(например Ć в unicode U+0106), потом сменить регистр(на ć), и только потом начинать сравнение. К слову, перекодировка нетривиальная задача. Причем это надо сделать 2 раза — для искомого и для всех «зарегистрированных» вариантов(существующих файлов, директорий, и т.д.) на пути. Кроме того тут присутствует не только чтение из памяти, но и запись в нее.
В итого это большой расход памяти, нагрузка на кэш процессора и на шину данных памяти. Если Вы посмотрите сколько сравнений приходится делать FS для того чтоб открыть file.txt, то сразу станет понятно что к чему.
Ну и есть, конечно, эстетический аспект. Я бы возмутился, если бы ко мне обращался человек как к NiAmStEr.
Смущает. Уже давно пытаюсь понять причину, как в языках программирования так и в FS (кроме привычки).
Основная масса — это никсовые FS. Которые по объёму не основная масса.
И есть у меня страшное подозрение, что регистрозависимость в никсах пошла из-за банальной экономии ресурсов (ведь так банально проще).
И есть у меня страшное подозрение, что регистрозависимость в никсах пошла из-за банальной экономии ресурсов (ведь так банально проще).
Это как же так? Вы хотите сказать, что подавляющее количество серверов использует Win или OSX?
К тому же Android использует ext4 в 90% случаев. Если еще сюда добавить сетевое оборудование и т.д. — думаю что *nix в большинстве =).
Википедия позволяет быть ближе к реальности.
К тому же Android использует ext4 в 90% случаев. Если еще сюда добавить сетевое оборудование и т.д. — думаю что *nix в большинстве =).
Википедия позволяет быть ближе к реальности.
Пробовал жить на HFS+ с учетом регистра клавиатуры. Год на ней где-то был. Из проблем — только запускаемый из контейнера Steam. Все остальное работало штатно. Проблемы были при переезде на том без учета регистра. Но это была не необходимость, а от «нечего делать».
В документации написано, что это временное ограничение, которое может быть устранено в последующих версиях и/или в релизе APFS в 2017 году.
Было бы интересно почитать обзор на тему почему все же не взяли ZFS. Несколько раз же пытались перенести.
А так ждем, жаль только что реализации для Linux скорее всего не скоро увидим.
А так ждем, жаль только что реализации для Linux скорее всего не скоро увидим.
где-то видел что ZFS чувствительна к ошибкам озу, поэтому дальше серверов вряд ли уйдёт.
UFO just landed and posted this here
Мне в BTRFS (и ZFS) нравится возможность прозрачно добавлять/удалять тома в существующую систему. Хотя сейчас мало кто уже открывает крышку компьютера без необходимости и эта фича не востребована.
В LVM это тоже есть.
LVM управляет только томами. Файловая система должна уметь расширяться и сжиматься при изменении размеров тома, что обычно непрозрачно (требует размонтирования). Да и у FS больше информации как разместить данные на нескольких носителях.
Так вроде вы выше и писали про «добавлять/удалять тома». Многие системы не требуют размонтирования для расширения, а только для сжатия, даже NTFS, кажется, умеет.
Насколько я знаю, у Btrfs проблемы со стабильностью, а ZFS ещё не до конца портировали на Linux, когда последний раз в этом ковырялся, оказалось проще переехать на LVM. А вот дополнительные возможности ZFS при работе с физическими носителями разного типа весьма полезны, тут полностью согласен.
Насколько я знаю, у Btrfs проблемы со стабильностью, а ZFS ещё не до конца портировали на Linux, когда последний раз в этом ковырялся, оказалось проще переехать на LVM. А вот дополнительные возможности ZFS при работе с физическими носителями разного типа весьма полезны, тут полностью согласен.
Думаю, если не лицензия, то, скрорее всего из-за прожорливаости ZFS к ОЗУ, а на телефоне или айпаде памяти и так мало.
ZFS хоть и открыта, но все тёрки идут из-за несовместимости лицензий и сейчас в прямом смысле бодаются юристы, чтобы сказать «кто прав, а кто виноват».
А работу с томами на уровне FS они не стали поддерживать. :-(
Возможно, это связано с тем, что они считают/пропагандируют что компьютер надо заменять целиком, а рабочие данные хранить в облаке.
Возможно, это связано с тем, что они считают/пропагандируют что компьютер надо заменять целиком, а рабочие данные хранить в облаке.
Интересно, то есть дедупликация давно есть в Linux, скоро появится в MacOS и отсутствует только под Windows...
Дедупликация уже есть в Windows Server:
https://habrahabr.ru/company/microsoft/blog/158887/
https://habrahabr.ru/company/microsoft/blog/158887/
Я её смотрел. Это какое-то странное решение, которое страшно даже для домашнего использования:
- дедупликация реализована не на уровне файловой системы, а на уровне приложения через File Streams;
- файлы распадаются на метаданные и данные;
- нет API для создания копии файла;
- нельзя грузиться с раздела, на котором настроена дедупликация;
- пенальти на производительность.
У меня сложилось впечатление, что данная фича в Windows сделана для галочки в рекламных буклетах.
Дедупликации на уровне файловой системы в Windows нет и, судя по всему, не планируется.
Регистрозависимость удобна когда есть git репозитории которые регистрозависимы.
Работаю с репозиториями с которыми git работал некорректно из за регистронезависимой (по умолчанию) HFS+
Обхожу созданием дополнительного диска с HFS+ регистрозависимой файловой системой и храню оные git репозитории там.
Почему то содержимое git репозиториев на этом диске иногда портится.
В связи с чем: отличная новость, буду рад попробовать APFS для хранения регистрозависимых файлов.
Работаю с репозиториями с которыми git работал некорректно из за регистронезависимой (по умолчанию) HFS+
Обхожу созданием дополнительного диска с HFS+ регистрозависимой файловой системой и храню оные git репозитории там.
Почему то содержимое git репозиториев на этом диске иногда портится.
В связи с чем: отличная новость, буду рад попробовать APFS для хранения регистрозависимых файлов.
Эра бета-версий во всей красе. Apple выпускают незаконченную версию файловой системы и говорят: «тестируйте, но вы можете потерять все свои данные». Я понимаю, когда авторы видео-плеера предлагают бета версию своего продукта с новыми плюшками. Но когда корпорация рекламирует недоделанный продукт с закрытым исходным кодом, использование которого может (теоретически) повредить часть данных, то мне кажется, что где-то мы свернули не туда.
ИМХО, бета версии, частые релизы, новые фичи два раза в год, поддержка свежих эмодзи — это не то, что Я хочу видеть от производителя драйвера файловой системы. Мне кажется, что в таких критических системах должна рекламироваться надёжность, производительность и отказоустойчивость.
ИМХО, бета версии, частые релизы, новые фичи два раза в год, поддержка свежих эмодзи — это не то, что Я хочу видеть от производителя драйвера файловой системы. Мне кажется, что в таких критических системах должна рекламироваться надёжность, производительность и отказоустойчивость.
Так вроде они и не предлагают ставить ее на носители с важной информацией. Мне как раз было бы тревожнее, если бы они сразу ее объявили, как конечную версию и начали бы ее активно рекламировать. Поскольку, как не тестируй, какие-то ошибки в первое время будут всплывать и для начала ее обкатывают на энтузиастах.
Я не припомню, чтобы кто-нибудь выпускал бета-версию нового стандарта Wi-Fi, или пробную версию RAID контроллеров, или незаконченный драйвер видеокарты (исключение составляют только активно разрабатываемые операционные системы, наподобие ReactOS, Fantom OS, др.). Я ожидаю что такой важный компонент, как файловая система, должен быть отлажен, покрыт unit-тестами, проверен на различном железе, а только потом доступен всем желающим.
Странно, что разработчики смирились с фактом «как не тестируй, какие-то ошибки в первое время будут всплывать». Поэтому сейчас эра бета-версий в самом разгаре.
Странно, что разработчики смирились с фактом «как не тестируй, какие-то ошибки в первое время будут всплывать». Поэтому сейчас эра бета-версий в самом разгаре.
Sign up to leave a comment.
Файловая система Apple File System (APFS)