Comments 102
Костыль на костыле вместо того, чтобы реализовать нативный драйвер ext3 или btrfs. Впрочем, кто бы сомневался.
> вместо того, чтобы реализовать нативный драйвер ext3 или btrfs.
Причем тут драйвер файловой системы вообще? :D Вы точно суть проблемы поняли? Совсем грубо говоря — у вас может быть сколь угодно нативный драйвер, но в винде конец строки — одна последовательность символов, а в линуксе — другая. И виндовые инструменты через замечательный нативный драйвер замечально запишут битый конфигурационный файл. И таких различий может быть очень много.
Фактически, вмешиваясь виндовыми инструментами в подсистему Linux, вы с помощью внешней ОС работаете с образом другой ОС. Делать так можно только тогда, когда вы абсолютно точно понимаете, на что ваше вмешательство повлияет. О чём, собственно, и речь.
Причем тут драйвер файловой системы вообще? :D Вы точно суть проблемы поняли? Совсем грубо говоря — у вас может быть сколь угодно нативный драйвер, но в винде конец строки — одна последовательность символов, а в линуксе — другая. И виндовые инструменты через замечательный нативный драйвер замечально запишут битый конфигурационный файл. И таких различий может быть очень много.
Фактически, вмешиваясь виндовыми инструментами в подсистему Linux, вы с помощью внешней ОС работаете с образом другой ОС. Делать так можно только тогда, когда вы абсолютно точно понимаете, на что ваше вмешательство повлияет. О чём, собственно, и речь.
Вам встречный вопрос тот же: вы понимаете суть проблемы? Вы понимаете разницу между содержимым файлов и метаданными?
А если вы уж так хорошо это понимаете — то объясните как нативный драйвер ext3 смог бы решить эту проблему? Чем он отличался бы от уже существующих и как бы он смог помешать Windows-редактору убивать все ACL'и?
Про ACL речь не шла вообще, это уже опциональная надстройка, они бы хотя бы с голым ext разобрались. Вы бы ещё спросили, как винде взаимодействовать с apparmor или selinux.
Проблема бы решилась так, что эти «метаданные», упомянутые в статье, брались бы драйвером из файловой системы, а не из какого-то внешнего неконсистентного хранилища. Uid и gid для ext раздела можно было бы спрашивать у юзера при подключении тома.
Проблема бы решилась так, что эти «метаданные», упомянутые в статье, брались бы драйвером из файловой системы, а не из какого-то внешнего неконсистентного хранилища. Uid и gid для ext раздела можно было бы спрашивать у юзера при подключении тома.
> что эти «метаданные», упомянутые в статье, брались бы драйвером из файловой системы
Вы понимаете, что файл РЕДАКТИРУЕТСЯ? И, в общем случае, драйвер не может просто взять и оставить ему те же метаданные, которые были раньше? И даже вообще нельзя сказать, является ли файл тем же самым? Вот софтина берет, при сохранении удаляет старый файл, и под тем же именем создаёт новый. Какой «нативный драйвер» файловой системы вам сам по себе запишет «правильные» метаданные, откуда он их вообще возьмет? Он просто драйвер, он обязан записать ровно то, что просит софтина. А она пишет кривые данные.
Вы понимаете, что файл РЕДАКТИРУЕТСЯ? И, в общем случае, драйвер не может просто взять и оставить ему те же метаданные, которые были раньше? И даже вообще нельзя сказать, является ли файл тем же самым? Вот софтина берет, при сохранении удаляет старый файл, и под тем же именем создаёт новый. Какой «нативный драйвер» файловой системы вам сам по себе запишет «правильные» метаданные, откуда он их вообще возьмет? Он просто драйвер, он обязан записать ровно то, что просит софтина. А она пишет кривые данные.
> Вы понимаете, что файл РЕДАКТИРУЕТСЯ? И, в общем случае, драйвер не может просто взять и оставить ему те же метаданные, которые были раньше?
Что значит «не может оставить»? Именно это и делают все вменяемые файловые системы при редактировании файла. Запись в файловой таблице (inode) для файла останется одной и той же, пишите в него хоть 0 байт, хоть Войну и мир. Меняется количество и адреса блоков с содержимым, но это уже другой вопрос, они не являются метаданными.
> Вот софтина берет, при сохранении удаляет старый файл, и под тем же именем создаёт новый.
В общем случае так не происходит — редактируется старый inode. Если всё же происходит, то вопрос сводится к «какие метаданные выставлять для нового файла?» Это вопрос сложный из-за сложности и количества метаданных, но если бы я был пользователем wsl, мне было бы достаточно грубого решения в первом приближении: «Время доступа взять из системных часов Windows. UID, GID, флаги chmod — спросить в начале у юзера.»
Что значит «не может оставить»? Именно это и делают все вменяемые файловые системы при редактировании файла. Запись в файловой таблице (inode) для файла останется одной и той же, пишите в него хоть 0 байт, хоть Войну и мир. Меняется количество и адреса блоков с содержимым, но это уже другой вопрос, они не являются метаданными.
> Вот софтина берет, при сохранении удаляет старый файл, и под тем же именем создаёт новый.
В общем случае так не происходит — редактируется старый inode. Если всё же происходит, то вопрос сводится к «какие метаданные выставлять для нового файла?» Это вопрос сложный из-за сложности и количества метаданных, но если бы я был пользователем wsl, мне было бы достаточно грубого решения в первом приближении: «Время доступа взять из системных часов Windows. UID, GID, флаги chmod — спросить в начале у юзера.»
В общем случае так не происходит — редактируется старый inode.Какой нафиг «старый inode»? Подавляющее большинство Windows-редакторов удаляют старый файл и кладут на его место новый. Откуда тут «старый inode» возьмётся?
«Время доступа взять из системных часов Windows. UID, GID, флаги chmod — спросить в начале у юзера.»Это как? Это значит что у меня какой-нибудь Notepad-Extra-Plus будет 100 диалоговых окон открывать чтобы ему на все 100 временных файлов, которые он создаёт пользователь выдывал UID и GID?
Я запутался, о какой ФС идёт речь.
Для ext3 тома решение — сделать для программы примонтирования ext тома настройки «дефолтный uid», «дефолтный gid» и т.д. Примерно как это делается в линуксе в опциях к mount.ntfs, только наоборот.
Для ntfs тома решение — убрать нафиг подход «разваливающееся хранилище метаданных для файлов Linux» и вместо этого ввести в wsl правила трансляции ntfs метаданных в ext метаданные для stat(2) и umask(2) с человеческими дефолтами.
Для ext3 тома решение — сделать для программы примонтирования ext тома настройки «дефолтный uid», «дефолтный gid» и т.д. Примерно как это делается в линуксе в опциях к mount.ntfs, только наоборот.
Для ntfs тома решение — убрать нафиг подход «разваливающееся хранилище метаданных для файлов Linux» и вместо этого ввести в wsl правила трансляции ntfs метаданных в ext метаданные для stat(2) и umask(2) с человеческими дефолтами.
Я запутался, о какой ФС идёт речь.А как файловая система вообще на что-либо влияет?
Для ext3 тома решение — сделать для программы примонтирования ext тома настройки «дефолтный uid», «дефолтный gid» и т.д.И как это вам поможет если вы suid'ную программу скопируете?
Примерно как это делается в линуксе в опциях к mount.ntfs, только наоборот.Если вы скопируете системные файлы из одного места в другое средствами Linux — то у вас после этого Windows может запросто перестать загружаться. Собственно на примере Linux'а можно легко увидеть что ваше мегапредложение не работает. И не может работать — ибо вообще не ту проблему решает.
Для ntfs тома решение — убрать нафиг подход «разваливающееся хранилище метаданных для файлов Linux» и вместо этого ввести в wsl правила трансляции ntfs метаданных в ext метаданные для stat(2) и umask(2) с человеческими дефолтами.Ещё раз: нет там никакого «разваливающегося хранилища метаданных». И никогда не было. Ибо не нужно. NTFS отлично может хранить как POSIX аттрибуты, так и Windows аттрибуты. Могла с момента создания и за прошедшие годы этих возможностей не потеряла. Проблема — совсем в другом.
Так что мешает Микрософту сделать системный вызов вида «хочу делать что-то стремное с линуксовым файлом»? И если программа его не сделала, задавать тупой вопрос пользователю?
На самом деле базовую трансляцию прав доступа Linux в ACL можно сделать и это решит хотя бы часть проблем. Программы редакторы файлов для Windows должны же сохранять старые ACL после изменения файла в терминах пользовательского интерфейса. Как вариант можно в ACL добавить UNIX пользователей и группы и возможно и обратно Windows-пользователей и группы в UNIX. В принципе ACL можно поместить базовые права Unix-пользователей для файлов: чтение, выполнение, запись. С установкой прав для владельца файлов, если будет он будет присутсвовать в Windows, в Linux уже не будет проблем, также можно добавить группу UNIX-пользователей, чтобы устанавливать флаги для остальных пользователей в WSL. Остаётся держать эти права в синхронизации.
C SUID уже проблемы, но тут вряд ли Windows программы маловероятно будут редактировать исполняемые файлы для Linux. А для остальных функций WinAPI: (копирования например), сделать так, чтобы они учитывали права Linux в NTFS. Проблему с SUID можно решить костыльно: создать fake-пользователя, присутствие которого будет означать, что запускать с правами владельца или хранить это в реестре, как это делает совместимость приложений.
Насчёт создания нового файла можно для каждого приложения прикрепить контекст UNIX-пользователя. Например, можно чтобы проводник и все приложения Windows работали с правами пользователя user в Linux для файлов WSL. И уже в API предусмотреть смену текущего UNIX-пользователя от которого идёт работа с файлами WSL через Win32-приложения.
Моё IMHO как можно, если не решить, то хотя бы улучшить положение дел с взаимодействии прав WSL-Win32
C SUID уже проблемы, но тут вряд ли Windows программы маловероятно будут редактировать исполняемые файлы для Linux. А для остальных функций WinAPI: (копирования например), сделать так, чтобы они учитывали права Linux в NTFS. Проблему с SUID можно решить костыльно: создать fake-пользователя, присутствие которого будет означать, что запускать с правами владельца или хранить это в реестре, как это делает совместимость приложений.
Насчёт создания нового файла можно для каждого приложения прикрепить контекст UNIX-пользователя. Например, можно чтобы проводник и все приложения Windows работали с правами пользователя user в Linux для файлов WSL. И уже в API предусмотреть смену текущего UNIX-пользователя от которого идёт работа с файлами WSL через Win32-приложения.
Моё IMHO как можно, если не решить, то хотя бы улучшить положение дел с взаимодействии прав WSL-Win32
Извиняюсь, я думал, что речь про редактирование файлов на ext3 томе, и все мои ответы были на эту тему. Если речь идёт про файлы на ntfs томе, то у меня впечатление всё то же самое — подход костыльный, какой-то «файл метаданных для линуксовых файлов». Стабильный источник метаданных — файловая система. Не думаю, что для WSL большая проблема ввести вменяемые правила и дефолты для трансляции ntfs-метаданных в данные для системного вызова umask().
Не думаю, что для WSL большая проблема ввести вменяемые правила и дефолты для трансляции ntfs-метаданных в данные для системного вызова umask().За прошедшие четверть века подобного в другом направлении придумать не удалось: если вы сегодня перенесёте Windows-систему с одного NTFS-раздела на другой с помощью Linux'овых программ (cp или там tar), то полученная система работать не будет.
Тут — та же самая ситуация в противоположном направлении. И никакая «поддержка ext3» проблемы не решит. Скорее усугубит: NTFS может хранить все метаданные — и нужные для Windows-приложений и нужные для POSIX/Linux-приложений. ext3 — на это неспособна.
ext3 — на это неспособна.Really?
Не сваливайте неумение юзерспейса на ФС.
Что NTFS, что EXT3 — могут хранить всё. Впрочем, юзерспейс Windows от этого никак не научится работать с метаданными Linux, и наоборот.
В NTFS есть альтернативные потоки. Не подскажете, способны ли xattr их эмулировать в полной мере?
(Я оставлю за скобками вопрос первостепенной важности и необходимости. Просто примем, что они всё-таки нужны.)
Что NTFS, что EXT3 — могут хранить всё.Ну в каком-то глубоко философском плане — да, наверное. Но как вы собрались вот скажем эту табличку в ext3 засовывать?
Не сваливайте неумение юзерспейса на ФС.Ну знаете. Как вы это себе представляете? Создал Вася файл с названием «AaA», а Петя хочет создать файл названием «aAa» — ему дадут это сделать или нет? Если дадут — то будет этот тот же самый файл или нет?
Впрочем, юзерспейс Windows от этого никак не научится работать с метаданными Linux, и наоборот.Всё гораздо хуже. В ext3 некуда засунуть кучу вещей нужных для Windows userspace. Upcase table, «короткие имена» и многое чего ещё.
Заметьте: мы тут не обсуждаем — полезно ли в принципе иметь эти фичи или нет. Важно то, что они есть в NTFS, их нет в ext3 — и без них Windows работать не сможет. Всё.
ext3 — гораздо лучше NTFS по многим параметрам. Но вот вопросы совместимости с Windows userspace — нет, тут ext3 «не годится».
Ну в каком-то глубоко философском плане — да, наверное. Но как вы собрались вот скажем эту табличку в ext3 засовывать?Ну, никто не мешает точно так же как и в NTFS — файликом. Нужно только придумать как его спрятать :)
Ну знаете. Как вы это себе представляете? Создал Вася файл с названием «AaA», а Петя хочет создать файл названием «aAa» — ему дадут это сделать или нет? Если дадут — то будет этот тот же самый файл или нет?NTFS умеет файлы с различием только в регистре. Что и подтверждает WSL.
А вот софт под Windows и подсистема Win32 — не умеет. Поэтому, дадут или нет, зависит от того, с использованием каких функций создается файл.
Всё гораздо хуже. В ext3 некуда засунуть кучу вещей нужных для Windows userspace. Upcase table, «короткие имена» и многое чего ещё.Короткие имена не нужны сейчас уже практически никому, и ReFS их не поддерживает. Старому софту только. Upcase table — это да.
Но вот вопросы совместимости с Windows userspace — нет, тут ext3 «не годится».Хм, я изначально не совсем правильно понял что вы хотели сказать — почему-то решил что речь идет только об ACL.
Каюсь, был неправ.
Хотя, с другой стороны, Windows (до XP включительно) вполне себе может работать на FAT… и я не припомню ничего такого, что умеет FAT и не умеет ext* :)
Короткие имена не нужны сейчас уже практически никому, и ReFS их не поддерживает.Операционной системе они нужны. А на ReFS Windows поставить нельзя — в частности и поэтому тоже.
Хотя, с другой стороны, Windows (до XP включительно) вполне себе может работать на FAT… и я не припомню ничего такого, что умеет FAT и не умеет ext* :)Короткая же у вас память, однако: а как же неразличимость строчных и прописных букв и короткие имена файлов? Вот только что ведь обсуждали!
Ещё раз: то, что эти фичи «кривые и косые» и ext3 умеет много чего ещё — абсолютно неважно на фоне того, что Windows-софт без поддержки этих вещей работать не будет.
Их можно попытаться эмулировать (в конце-концов samba это делает), но это — будут те ещё костыли.
UFO just landed and posted this here
Не надо рассказывать сказок, а? В реестре отключается создание коротких имён. Те, которые уже есть — остаются и могут быть использованы.
И таки для некоторых ключевых каталогов это важно — есть компоненты, которые лезут во все эти «PROGRA~1» именно по короткому имени.
С отличием «a» от «A» — та же история: вы можете разрешить программам их отличать — но все «старые», «неразумные» программы их отличать не будут.
Да, возможно, забив ещё десяток костылей в разные места — можно было бы и добиться того, чтобы Windows смогла бы запуститься с ext3… но зачем? Если на NTFS всё прекрасно работает и так?
И таки для некоторых ключевых каталогов это важно — есть компоненты, которые лезут во все эти «PROGRA~1» именно по короткому имени.
С отличием «a» от «A» — та же история: вы можете разрешить программам их отличать — но все «старые», «неразумные» программы их отличать не будут.
Да, возможно, забив ещё десяток костылей в разные места — можно было бы и добиться того, чтобы Windows смогла бы запуститься с ext3… но зачем? Если на NTFS всё прекрасно работает и так?
Операционной системе они нужны.Сомневаюсь — их можно отключить, и удалить уже созданные.
Впрочем, информации о нужности либо ненужности не нашел, поэтому на 100% не скажу.
Короткая же у вас память, однако: а как же неразличимость строчных и прописных букв и короткие имена файлов? Вот только что ведь обсуждали!Неразличимость строчных и прописных букв — это дело драйвера, а не ФС. Вот для ext3 кто-то написал драйвер который не различает регистр. Аналогично, NTFS умеет различать регистр.
Короткие имена? Элементарно можно записать в xattr, в самой ФС всё есть. Только никому не нужно — поэтому драйвер этого не делает.
Windows-софт без поддержки этих вещей работать не будет.Будет, но не весь :) Тот же SQL Server не будет нормально работать, как минимум, без Alternate data streams и VSS. А какому-нибудь Total Commander пофиг, он и под Wine в Linux работает.
И да, вопрос кому надо запускать Windows с ext3 — правда интересный. Мне это точно не нужно, смысла нет :)
ext3 — гораздо лучше NTFS по многим параметрам.Интересно чем же лучше?
Насчет хуже — в ней нет экстентов (добавили в Ext4) и ACL, и журналирование прикручено сбоку (его можно игнорировать), например.
Не более костыльный, чем UMSDOS в Linux. Если вы, конечно, застали это извращение. Так вот, это то же самое и с подобным эффектом.
Про ACL речь не шла вообще, это уже опциональная надстройка, они бы хотя бы с голым ext разобрались.Нифига ж себе заявы. Стандартные rwxrwxrwx — это, как бы, тоже ACL'и и без них не будет работать в Linux ничего. А в Windows API — их нету. Совсем нету. Не предусмотрены.
Проблема бы решилась так, что эти «метаданные», упомянутые в статье, брались бы драйвером из файловой системы, а не из какого-то внешнего неконсистентного хранилища.Вы таки не поверите: они и сейчас берутся из файловой системы, а не из какого-то «внешнего хранилища». Все эти аттрибуты в NTFS есть — с самого начала есть!
А вот в Win32 API — их нету. Потому как только «Linux-файл» потрогает какой-нибудь FAR — он свои права доступа теряет. И перестаёт работаеть. Как тут помог бы драйвер ext3, я извиняюсь?
Извиняюсь, мы видимо про разные ACL говорили. Я имел в виду POSIX ACL, а они являются расширением.
Если речь про rwxrwxrwx, то ответ на ваш вопрос называется umask.
Если речь про rwxrwxrwx, то ответ на ваш вопрос называется umask.
Если речь про rwxrwxrwx, то ответ на ваш вопрос называется umask.Отсутствующий в Win32 API. Дальше что? Как несуществующий umask будет «спасать» файлы, которые редактируются Windows-редактором?
Редактор пусть сохраняет файлы так же как он делал 10 лет назад. Вопрос в том, какие данные сообщать вызовам stat(2) и umask(2), поступившим в WSL от юниксовых утилит, имея на руках только NTFS-метаданные. Правильный ответ — «организовать правила трансляции». Неправильный ответ от Microsoft, чреватый проблемами — «создавать и хранить синтетические метаданные, следя за их целостностью».
Неправильный ответ от Microsoft, чреватый проблемами — «создавать и хранить синтетические метаданные, следя за их целостностью».Это кто ж вам про такой «ответ» рассказал? Не надо его больше слушать.
Нет там никаких синтетических метаданных! NTFS способна хранить все данные: как создаваемые и используемые Windows-программами, так и создаваемые и используемые Linux-программами! Она так изначально создавалась! В ней эта поддержка всегда была — с момента создания проекта NT!
Проблема в другом — проблема в том, что если метаданные, нужные для работы Linux-прилождений (скажем SUID-бит), Windows-программа, не знающая об их существовании, я извиняюсь, «похерит» — то взять из будет попросту неоткуда! И Linux перестанет работать. Всё.
Причём тут ext3, костыли и трансляция? Как они SUID-бит вернут?
Тьфу чёрт, я думал, что речь про редактирование файлов на ext3 томе, и все мои ответы были на эту тему.
А что это меняет? Все права доступа и прочее — есть и на NTFS и на ext3, «теряются» они также одинаково успешно в обоих случаях. Нафига козе баян?
Поддержка ext3 не решила бы ни одной проблемы из числа обсуждавшихся в статье. Ни одной. А новых — да, могла бы насоздавать. Начиная с того, что уже Windows-аттрибуты файлов начали бы теряться (в том числе не только метаданные, но и данные тоже).
Поддержка ext3 не решила бы ни одной проблемы из числа обсуждавшихся в статье. Ни одной. А новых — да, могла бы насоздавать. Начиная с того, что уже Windows-аттрибуты файлов начали бы теряться (в том числе не только метаданные, но и данные тоже).
UFO just landed and posted this here
Тогда и FAT нужно запретить, там нет альтернативных файловых потоков.FAT запрещён начиная с Windows Vista. Кажется уже Windows 2003 на FAT не ставится, но Windows Vista — точно встаёт только на NTFS. Именно потому что ей нужны фичи, отсутствующие в FAT.
А раз при наличии FAT всё работает, то и поддержка ext3 никаких новых не создаст.См. выше.
UFO just landed and posted this here
А зачем он тогда вообще будет нужен?
Нет, поддержка ext3 — была бы неплоха, несомненно. Но для установки Windows, позволяющей запускать приложения Ubuntu — она не годится. Никак.
Нет, поддержка ext3 — была бы неплоха, несомненно. Но для установки Windows, позволяющей запускать приложения Ubuntu — она не годится. Никак.
UFO just landed and posted this here
А то можно сказать- зачем вообще эта подсистема нужна?Чтобы подсадить разработчиков для всяких Node.js и LAMP'ов на Visual Studio. Я об этом уже писал.
Или вы думаете есть какая-то другая цель?
UFO just landed and posted this here
В том-то и дело, что от ответа на ваш риторический вопрос зависит полезность или бесполезность поддержки ext3! Для решения вышеописанной задачи — поддержка ext3 не нужна и даже вредна.
Задача ведь по прежнему стоит как «удержание как можно большего количества разработчиков в среде Windows». А драйвер ext3, скорее, будет провоцировать делать всякие dual boot'ы и прочее. Зачем оно Microsoft'у?
Задача ведь по прежнему стоит как «удержание как можно большего количества разработчиков в среде Windows». А драйвер ext3, скорее, будет провоцировать делать всякие dual boot'ы и прочее. Зачем оно Microsoft'у?
Проблема не в том, что драйвер файловой системы что-то портит, а в том, что виндовые инструменты, с помощью которых редактируются файлы, дают этому драйверу некорректную информацию для записи. Внутри она файлов, в метаданных или ещё где — вообще говоря, неважно.
Вам бы тоже стоило прочитать статью ещё раз. Речь тут не о концах строк (это данные), а правах доступа (метаданных). Вся проблема в красках описана (правда на английском языке) уже много-много лет назад.
Правда надо признать, что разработчики CygWin'а схалтурили меньше, чем разработчики lxss: они «вложили»-таки Linux'овую систему прав доступа в Windows. Так что файлы создавать и редактировать Windows-программами можно — правда с некоторыми оговорками (если вы создаёте файл в папке c:\cygwin — всё работает, если где-нибудь «сбоку» — то могут быть эксцессы). Товарищи же из Microsoft этот кактус только-только начали жевать — неудивительно, что у них не слишком хорошо получилось.
Правда надо признать, что разработчики CygWin'а схалтурили меньше, чем разработчики lxss: они «вложили»-таки Linux'овую систему прав доступа в Windows. Так что файлы создавать и редактировать Windows-программами можно — правда с некоторыми оговорками (если вы создаёте файл в папке c:\cygwin — всё работает, если где-нибудь «сбоку» — то могут быть эксцессы). Товарищи же из Microsoft этот кактус только-только начали жевать — неудивительно, что у них не слишком хорошо получилось.
Что нибудь придумают со временем, думаю.
Неа. Можно только распродажу губозакатывательных машинок устроить.
Проблема не в том, что Linux — отличная система прав доступа, а в Windows — отстойная (или наоборот). Проблема в том, что они разные.
Единственная возможность — научить все Windows-программы работать с обоими. Если бы эта подсистема была в Windows изначально и активно использовалась — тогда был бы шанс. А так — разве что самые популярные программы для backup'а поправят. И то на это несколько лет уйдёт.
Проблема не в том, что Linux — отличная система прав доступа, а в Windows — отстойная (или наоборот). Проблема в том, что они разные.
Единственная возможность — научить все Windows-программы работать с обоими. Если бы эта подсистема была в Windows изначально и активно использовалась — тогда был бы шанс. А так — разве что самые популярные программы для backup'а поправят. И то на это несколько лет уйдёт.
Разные то разные, но у CygWin же работает.
на самом деле, если отучить виндовские программы удалять файл и создавать новый с тем же именем, а вместо этого именно редактировать — менять имеющийся — большое число проблем решится. Именно так и действуют линуксовые редакторы
Можно просто не удалять метаданные если один файл перезаписывается другим.
Нет такого понятия в интерфейсах ФС — "перезаписывается". Это вам интерактивные среды говорят и показывают композитную операцию "перезапись", а на самом деле они под капотом стирают старый и переименовывают временный в то имя, которое было у старого.
Среди интерфейсов ФС есть вариант открыть файл для изменения. Для этого вместо стирания старого и переименовывания в его имя готового временного файла придётся читать данные из временного его и записывать в открытый для изменения старый, затирая то, что там было, т.е. копировать. В общем, тонкости есть.
Можно даже проверить каждую конкретную программу, как именно она действует — сравните номер inode старого файла и файла после "перезаписи".
они под капотом стирают старый и переименовывают временный в то имя, которое было у старого.
Это и называется перезаписью. Вам объяснить как это детектировать или сами догадаетесь?
При этом метаданные удаляются при стирании старого файла — вместе с ним. Их нельзя не удалить: ведь объект, к которому они относились, перестаёт существовать.
На этот момент ФС неизвестно, что последует за этим удалением. Может, другие удаления. Может, директорию, где был указанный файл, тоже удалят. А может, в его имя переименуют другой файл.
В процессе этого переименования метаданные временного файла становятся метаданными результата "перезаписи". Они же были на нём, когда он был временным, и операция переименования ничто, кроме имени затронуть не должна — значит, метаданные должны остаться не как у того файла, как удалили, а как у того, который создавали временно.
Нужно понимать, что после перезаписи это совершенно новый файл, со своей собственной историей. Другой. В его истории не было метаданных старого файла, которые могли бы быть "удалены". Чтобы метаданные у него стали как у старого, их нужно не "не удалять", а "установить такими, какими были у старого".
Это две дополнительных операции, сверх удаления и переименования. И автоматически это сделано быть не может, поскольку сами по себе примитивы "удалить" и "переименовать" не всегда используются совместно.
Вы гитом когда-нибудь пользовались?
При чём тут гит?
Он тоже хранит метаданные и как-то справляется с детектированием перезаписи безо всяких "интерфейсов ОС".
UFO just landed and posted this here
С перезаписью справляется прекрасно.
Про переименовывание мы говорим в другой ветке: https://habrahabr.ru/post/315594/#comment_9919334
Он даже не пытается это делать. В этом — гений Линуса.
Вместо этого он вычисляет эти данные во время показа истории — отсюда все эти опции -M, -C, --no-renames, и прочие.
Некоторые другие системы контроля версий пытаются это делать и на этом основании принимать какие-то решения во время «заливки» изменений в историю. Это — ужасно.
В случае с git'ом вопрос «а тот это файл или нет» можно задать 10 раз — и получить на него 5 раз ответ «да» и пять раз ответ «нет» — в зависимости от настроек того, кто спрашивает.
Так что ссылка на git скорее уж должна была быть у оппонентов другой стороны…
Вместо этого он вычисляет эти данные во время показа истории — отсюда все эти опции -M, -C, --no-renames, и прочие.
Некоторые другие системы контроля версий пытаются это делать и на этом основании принимать какие-то решения во время «заливки» изменений в историю. Это — ужасно.
В случае с git'ом вопрос «а тот это файл или нет» можно задать 10 раз — и получить на него 5 раз ответ «да» и пять раз ответ «нет» — в зависимости от настроек того, кто спрашивает.
Так что ссылка на git скорее уж должна была быть у оппонентов другой стороны…
Нет, всё проще. Гиту глубоко положить "тот" это файл или нет. Ему важно лишь где он лежит. И метаданные привязываются не к файлу, а к его имени. Именно поэтому перезапись не является для него проблемой. А копирование и переименовывание детектируется довольно просто, так как никто не занимается "созданием нового файла, переносом туда содержимого старого с последующим удалением старого".
И метаданные привязываются не к файлу, а к его имени.Это кто ж вам такую чушь сказал? Git не сохраняется подавляющее большинство метаданных вообще. Положите в git SUID'ный файл — вынете не SUID'ный. Тот мизер, что он сохраняет — он сохраняет там же, где и сами данные.
Ему важно лишь где он лежит.Не можете привести пример? А то как-то я вот не помню ни одной операции в git'е (кроме просмотра истории), где это было бы важно. Чтобы атрибуты привязывались в git'е к имени и на что-то влияли — это что-то новенькое.
Хреново он справляется. Там AFAIK файл считается изменённым, если менее 50% различий, что бы это ни значило. Впрочем, даже если один байт изменился, нельзя "детектировать" — см. https://habrahabr.ru/post/315594/#comment_9919280
Если вы тут мечтаете о логике вида "если некий файл удалили и на его место переименовали другой, задать новому атрибуты как были у старого" — нет, это недопустимая логика для ФС. Это стрельба себе в ногу. Представим, что я заменяю файл таким образом не потому, что я его редактировал, а потому, что я накатываю его новую версию. При этом я, внезапно, удаляю старый и переменовываю новый. И у новой версии уже должны быть её, новой версии, метаданные. В них может быть что угодно — собственно номер версии, цифровая подпись или MAC файла, и так далее. Нельзя, чтобы ФС самовольно сюда подставляла старые значения.
Короче, никакого детектирования!
Представьте, что новую версию файла вы получили на флешке с FAT или с компакт диска с CDFS. Представили? Тогда вы должны понять, почему метаданные, которые должны быть копируемыми, всегда кладут либо в сам файл (EXIF), либо в отдельный файл (.DS_Store). А в отдельном потоке ФС хранятся лишь метаданные, привязанные к этой ФС и которые при перемещении файла не жалко потерять.
Или, если подсистема линукс реально хранит метаданные в структурах NTFS, то не портить метаданные можно подходом "прочитал все метаданные файла в память, делаю с файлом что хочу, удаляю и прочая, но после записи файла с тем же именем — устанавливаю метаданные, которые я сохранял в память". Такой подход позволит не портить даже те метаданные, про которые эта программа не знает и знать ей вообще не было нужно. Любые ACL там и прочее. Даже те метаданные, которые сейчас пока ещё не придумали, но придумают в следующем релизе ОС.
Я бы считал редактор, который делает так, адекватным.
Или, если подсистема линукс реально хранит метаданные в структурах NTFS, то не портить метаданные можно подходом «прочитал все метаданные файла в память, делаю с файлом что хочу, удаляю и прочая, но после записи файла с тем же именем — устанавливаю метаданные, которые я сохранял в память».Такой подход «спасёт» текстовые редакторы, да. Но в природе кроме текстовых редакторов бывает масса разных других программ. И она вполне могут захотеть файлы не только редактировать но и копировать, переименовывать — и вообще делать с ними всё, что угодно.
Вопрос «тот же этот файл или уже нет» очень быстро потребует наличия полноценного искусственного интеллекта, я боюсь.
Если при этом они будут вызвать системные функции "скопировать" и "переименовать", а не велосипедить свою реализацию, то метаданные должны быть скопированы вместе с файлом.
Так я же и написал, "делаю с файлом, что хочу". Потом вы это повторяете и говорите, что именно поэтому не получится.
тут проблема в том, что программы переписывать придётся. Уже имеющиеся так и будут портить
Я специально написал, что это — очень грубый пример. Чтобы совсем точно дошло. К сожалению, товарищу не помогло. :)
Делать отдельный файл с дисковым образом ext4 для подсистемы линукса это тоже тот ещё костыль. Там уже и до обычной виртуалки недалеко.
Думаю, программистам майкрософта так было проще всего, но они все же запилили полноценный, а не сетевой доступ к файловой системе хоста.
Думаю, программистам майкрософта так было проще всего, но они все же запилили полноценный, а не сетевой доступ к файловой системе хоста.
Ядро NT изначально под это было заточено — и POSIX подсистема там была аж в самой первой версии NT (потом выпилили), так что нужно было только «пыль стряхнуть».
UFO just landed and posted this here
Речь не идёт о подсистемах ядра. Речь идёт о том, как хранить данные на диске (иначе причём тут ext3 вообще?). Так вот Windows 10 хранит атрибуты Linux-файлов так же, как это делал её далёкий предок во времена, когда он только разрабатывался!
Ещё раз: возможность хранить нужные для Linux'а атрибуты файлов — это не что-то, что Microsoft добавил в файловую систему Windows 10, это то, что туда закладывалось изначано, как часть проекта NT!
Ещё раз: возможность хранить нужные для Linux'а атрибуты файлов — это не что-то, что Microsoft добавил в файловую систему Windows 10, это то, что туда закладывалось изначано, как часть проекта NT!
Тенденция в любом случае хорошая, я верю, что в итоге получится юзабельный(а может быть даже хороший) продукт.
Я не смог прочитать всё беседу, поэтому просто отвечу на это замечание, нативный драйвер ext2/3/4 уже давно есть и работает. Вот только редактирование инструментами MSWin часто приводит к нехорошим последствиям (окончания строк, сброс флагов файла — может пропасть атрибут «x» после редактирования скрипта и т.п.).
ext2fsd который? Насколько помню, там есть проблемы с UAC (но это не проблема драйвера) + он мне как-то раз порушил ФС. Впрочем, я не обижаюсь — сам виноват, т.к. включил тестовую на тот момент функцию записи.
Ну и без журнала как-то не сильно хорошо:
Ну и без журнала как-то не сильно хорошо:
Unsupported Ext3/4 features:
1, journal: log-based operations, external journal
2, EA (extended attributes), ACL support
Ну, мне удалось заменить файлы убунты гентой.
И потом запустил уже гентовый баш :)
- Распаковал stage3 во временный каталог tmp1;
- Создал в проводнике в корне системы каталог tmp2;
- Переместил файлы Ubuntu в tmp2;
- Из tmp1 переместил (Crtl-X, Ctrl-V) корень генты.
И потом запустил уже гентовый баш :)
UFO just landed and posted this here
UFO just landed and posted this here
Развели тут бред насчет метаданных, которых в Линухе кот наплакал (если сравнивать с EAS или NTFS или уж NWFS).
Скорее всего проблема выеденного яйца не стоит — кривые программы(или библиотеки) в Линухе не могут отличить 0d от чужеродных 0d0a и впадают в ступор.
Скорее всего проблема выеденного яйца не стоит — кривые программы(или библиотеки) в Линухе не могут отличить 0d от чужеродных 0d0a и впадают в ступор.
0d на древних маках вроде принят был) А в остальных местах 0a или 0d 0a. Причем для первых нет никаких проблем нормально отображать вторые. Вот для тех, кто ждет два байта, существует проблема отображения переносов.
Вы вообще читали статью?
«WSL calculates and persists each Linux file’s metadata in its NTFS extended attributes.
However, Windows apps do not know how to (nor that they should) re-calculate & persist this Linux metadata each time they create/modify a file stored under your distro’s root (%localappdata\lxss\).
Therefore, if you use a Windows app/tool/console to create and/or modify a file under your distro root, it won’t have any Linux file metadata (e.g. permissions, owner, timestamps, etc.) stored in its extended attributes»
Проблемы с 0a есть разве что у кривых виндовых notepad-ов.
«WSL calculates and persists each Linux file’s metadata in its NTFS extended attributes.
However, Windows apps do not know how to (nor that they should) re-calculate & persist this Linux metadata each time they create/modify a file stored under your distro’s root (%localappdata\lxss\).
Therefore, if you use a Windows app/tool/console to create and/or modify a file under your distro root, it won’t have any Linux file metadata (e.g. permissions, owner, timestamps, etc.) stored in its extended attributes»
Проблемы с 0a есть разве что у кривых виндовых notepad-ов.
Вероятно, для кого-то будет полезно. Сам столкнулся с этой проблемой несколько месяцев назад, пришлось переустанавливать WSL. Проблема собственно была в обмене файлами между WSL и Windows собственно проблема решилась достаточно просто созданием symbolic link к папке Windows.
Как-то так:
файлы в папке c:\FilesForLinuх после этого доступны для изменения и в WSL и в самой Windows
Как-то так:
cd ~
ln -s /mnt/c/FilesForLinux
файлы в папке c:\FilesForLinuх после этого доступны для изменения и в WSL и в самой Windows
Простите мое занудство, но, ИМХО, заголовок немного неверный.
Из под винды МОЖНО изменять файло линукса, но вот что после этого будет — отдельный вопрос. :)
Тут скорей «Мы Вас предупредили, а дальше — вот нога, вот пистолет и сами думайте, что делать.»
Из под винды МОЖНО изменять файло линукса, но вот что после этого будет — отдельный вопрос. :)
Тут скорей «Мы Вас предупредили, а дальше — вот нога, вот пистолет и сами думайте, что делать.»
У меня недавно установщик винды сделал unallocated партишн с убунтой. Восстановіть через boot-repair не удалось.
Иначе как саботаж назвать не могу.
Вот вам и дуалбут.
Иначе как саботаж назвать не могу.
Вот вам и дуалбут.
Аналогичная проблема с метаданными на файлах в гетерогенных сетях уже давно решается в Samba. С ограничениями, но не такими чтобы пользователю нельзя было создавать или менять файлы. Docker for Window сейчас использует самбу и CIFS для реализации разделяемых томов. Это компромиссное решение, но чисто с практической точки зрения оно лучше, чем предлагаемое WSL.
Файловая подсистема в Windows содержит достаточно средств для гибкой работы с файлами (например, сжатие, шифрование и т.п.). Технология позволяет по аналогии сделать отдельный загончик для линуксячих файлов, со своими правилами для прозрачной трансляции метаданных в обе стороны.
Т.е. на концептуальном уровне приемлемое решение существует и есть возможности на уровне технологий. Это не какая-то там научная проблема. Реализовать (читай взять и сделать) в WSL — чисто техническая задача для инженеров из Microsoft.
Файловая подсистема в Windows содержит достаточно средств для гибкой работы с файлами (например, сжатие, шифрование и т.п.). Технология позволяет по аналогии сделать отдельный загончик для линуксячих файлов, со своими правилами для прозрачной трансляции метаданных в обе стороны.
Т.е. на концептуальном уровне приемлемое решение существует и есть возможности на уровне технологий. Это не какая-то там научная проблема. Реализовать (читай взять и сделать) в WSL — чисто техническая задача для инженеров из Microsoft.
С интересом прочитал дискуссию выше.
Кто-нибудь может объяснить почему аналогичной проблемы не возникает в обратном случае, т.е. при использовании wine и работе над одними и теми же файлами родными программами и программами, запущенными через wine? Или они есть, и просто я не сталкивался?
Кто-нибудь может объяснить почему аналогичной проблемы не возникает в обратном случае, т.е. при использовании wine и работе над одними и теми же файлами родными программами и программами, запущенными через wine? Или они есть, и просто я не сталкивался?
Или они есть, и просто я не сталкивался?Скорее всего так и есть. Врядли вы через wine редактировали исполняемые файлы, например :)
Подход другой. Wine эмулирует не всё, программы, которые требуют фич, которых Linux не имеет просто не работают.
WSL — гораздо более «честная» эмуляция, но как следствие файлы получают атрибуты, про которые Windows-программы ничего не знают.
Если бы Wine поддерживал всякие ADS — то вы получили бы эти проблемы в полной мере. Samba, кстати, в отличие от Wine это всё умеет — и именно поэтому при включении этих фич и попытке залезть «ручками» в каталог, экспортированный через Samba'у — можно поиметь подобные же проблемы.
WSL — гораздо более «честная» эмуляция, но как следствие файлы получают атрибуты, про которые Windows-программы ничего не знают.
Если бы Wine поддерживал всякие ADS — то вы получили бы эти проблемы в полной мере. Samba, кстати, в отличие от Wine это всё умеет — и именно поэтому при включении этих фич и попытке залезть «ручками» в каталог, экспортированный через Samba'у — можно поиметь подобные же проблемы.
Sign up to leave a comment.
Файлы подсистемы Linux нельзя создавать, изменять или удалять при помощи инструментов для Windows