Ext2fsd v0.46

> Виндой UDF как минимум на чтение поддерживается, правда не знаю увидится ли оно на флешке.

Не видится, пробовал.

> В ней нет файлов, нет файловой системы как таковой. В ней нет деления на дисковую и оперативную память... Очень удобно к слову.

Да-да. в PICK R83 и Advanced Pick была аналогичная фигня. Спору нет, пока работает - очень удобно. А вот если memory leak попёрли - плохо становится. Рекомендованный способ лечения - бакап, переустановка и восстановление. Может быть, в IBM есть коллеги которые пишут программы без ошибок, но что-то сомнительно...

> А вот если memory leak попёрли

Вообще прежде чем такое писать стоит поинтересоваться архитектурой AS/400. Я тебе раскрою большую тайну - там это невозможно. :) Вообще ей в этом году исполняется 20 лет и за это время она успела доказать свою надежность. Легенда о замурованном сервере именно про AS/400, точнее основана на реальной историей с AS/400

>Оно до сих пор не умеет монтировать диски при старте?..

можно! например, смотри здесь: http://www.pchelge.de/Ext2Fsd/Documents/FAQ.txt там где "Q) How to let system auto mount my ext2 partition when booting"

> причина - это устройства такие. остались еще от дос. и еще работают. com1 - 1-ый COM-порт prn (он же lpt1) - первый параллельный порт. и т.д.

Я у себя в линуксе могу создать /home/cvs/ttyS0 и ничего мне за это не будет, несмотря на наличие /dev/ttyS0

Вывод - ведекапец близится

Я уже много раз говорил: при создании com1, com2 ... выдает, что файл уже есть.

а при создании con выдает, что плохое имя файла.

А нафиг оно вообще нужно??

>на фат/фат32

ты в детстве головой ударился, или просто родился кретином?

а оно точно на java?

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

гы, то есть когда ставишь венду на фат32, то прав на файлах быть не может? Поделись пяточкой... ;)

Винда с Ext2fsd показывает квадратики на русских именах файлов. Как быть?

> Переименовать и удалить - в чем проблемы?

Пробовал, или так, белый шум создаёшь? Опиши всю последовательность шагов по удалению файла. Для определённости C:\asd?.txt

> Винда с Ext2fsd показывает квадратики на русских именах файлов. Как быть?

Перебирать возможные кодировки в опциях монтирования. Проще это делать из гуёвой программы настроек.

Пробовал только с utf-8.

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

> гы, то есть когда ставишь венду на фат32, то прав на файлах быть не может? Поделись пяточкой... ;)

На разделе с фат/фат32? Разумеется нет - на этих разделах ACL не поддерживается. А поскольку ты поставил систему на фат32, то вся система разделения прав идет лесом - как ты ни ограничивай юзера, он все равно сможет писать в любую часть раздела. Тоже самое - с разделами ext3fs. До мелкософта наконец-то доперло что это несекурно и способствует вирусне, посему висту ты можешь поставить только на ntfs. Плюс даже из-под админа прежде чем писать в системные пользователи надо поднять права, то есть UAC оборется.

>>> Два года юзал на ext3, для домашней файлопомойки стабильности более чем достаточно.

>> Достаточно посмотреть на список багфиксов за последние два года в сабже, чтоб понять что это 4.2 в чистом виде. :-)

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

А твое комент говорит только об одном - научись сцуко ходить по сцылкам! Ибо еслиб сходил, то понял что речь идет не о линухе плюс ext3fs, а о драйвере ext3fs под винду и об его крайней глючности и нестабильности.

а под слакой это работает?

> а под слакой это работает?

Слака не умеет Ext3FS? Зачем ты ее отучил от этого?

И у меня работало, правда с другим драйвером: http://fs-driver.org/

И ничего. Жалко только, что в режиме ext2, проверки больших разделов задолбали и теперь у меня jfs. Жалко, что из-под винды теперь когда делаешь лабу, музыку не послушаешь :(

format c:

я к сожалению пока жил под виндой только так мог решить проблему с часто внезапно возникающими неправильными именами

Скажу Вам по-секрету: такие имена в Windows создать МОЖНО. Хоть и не обычным путем, но - можно... Это так, для объективности только.

>дело не в экранировании. (если попробуешь экранировать, то кавычки тоже попадут в имя файла, т.е. не заэкранируется) причина - это устройства такие. остались еще от дос. и еще работают. com1 - 1-ый COM-порт prn (он же lpt1) - первый параллельный порт. и т.д.

C:\>mkdir 1

C:\>cd 1

C:\1>echo > \\.\C:\1\COM1

C:\1>dir Том в устройстве C не имеет метки. Серийный номер тома: 4582-BAD9

Содержимое папки C:\1

30.05.2008 21:40 <DIR> . 30.05.2008 21:40 <DIR> .. 30.05.2008 21:40 46 COM1 1 файлов 46 байт 2 папок 893 644 800 байт свободно

C:\1>del \\.\C:\1\COM1

"Учите матчасть!"(с)

Все там нормально. Второй год уже работает. И пишет и читает нормально. Работает как обычный раздел диска, то есть если не говорить что он ext2/3, то даже недогадешся, если не посмотриш в какойнибудь менеджер дисков. Я вот только на старом сижу драйвере. И там где мне довелось увидеть что винда раздел с ext2/3 видит как fat32. Не знаю как в новых. И еще если этот раздел смонтировать в линухе и перезагрузить его резтом, вобщем чтоб журнал был не очищеным, то в винде диск не смонтируется, пока не очистишь.

> format c:

Настолько предсказуемо, что даже не смешно.

С год назад чего только не пробовал, насоздавав таких файлов через ntfs-3g (глюки mc на HPFS с неправильно настроенной кодировкой). Под XP такие файлы и директории с ними не брали ни chkdsk, ни del, ни ren, ни rd /s, ни FAR, ни explorer. Удалил из-под линукса.

Надеялся, что существует (или появился в патчах) штатный способ лечения.

Да, шаблоны тоже не помогали.

>Да известно куда оно уходит. В них например хранится оценка (рейтинг) фотографии/трека/и т.д. Места на это к слову уходит немного. А то про что вы говорите это теневые копии, позволяющие хранить несколько версий файла. :-) Очень удобная система, я ее со всремен RSX-11 люблю. :

В нормальных ситуациях может это и полезно, а если какойнить шутник проситает журнал хакер и добавит в поток к файлу boot.ini образ dvd диска допустим. Четыре гига схавает, а размер boot.ini как был килобайты так и останется.

Если драйвер в установочный диск впихнеш то можно будет. nLite воспользоваться, собрать свой установочный диск xp с этими дровами и усе.

Альтернативные потоки реализуются в userspace на всех файловых системах, хоть fat.

Просто патчите библиотеку, чтобы readdir() не показывала файлы с символом `:' в названии. Вот я вся фича.

/me решил не ходить по ссылке

> Альтернативные потоки реализуются в userspace на всех файловых системах, хоть fat.

> Просто патчите библиотеку, чтобы readdir() не показывала файлы с символом `:' в названии. Вот я вся фича.

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

А ну-ка объясните из-за чего это ВНЕЗАПНО производительность упадет?

Разные хозяева и права доступа на потоки это фича, которая в ntfs появится лет через 30.

> А ну-ка объясните из-за чего это ВНЕЗАПНО производительность упадет?

А сам подумай - как происходит открытие файла? В случае если потоки реализованы нормально - поиск и создание дескриптора происходит ОДИН раз при открытие файла, при такой кривой реализации костылем - на КАЖДЫЙ поток. Падение производительности заметно даже на двух потоках - это когда data fork & resource fork из HFS эмулируются на FAT/FAT32, а если подоков хотя бы десяток...

> Разные хозяева и права доступа на потоки это фича

Это бага и этого быть не должно. Почему - домашнее задание. :-)

>В случае если потоки реализованы нормально - поиск и создание дескриптора происходит ОДИН раз при открытие файла, при такой кривой реализации костылем - на КАЖДЫЙ поток.

Винда отыскивает логические блоки занятые файлом линейным поиском? Или создание структуры в ядре медленнее чем IO ?

>Падение производительности заметно даже на двух потоках - это когда data fork & resource fork из HFS эмулируются на FAT/FAT32, а если подоков хотя бы десяток...

А каковы технические ограничения, могущие воспрепятствовать реализации такой фичи в ext2-3-4? Есть там какой-то фатальный Ньюанс? К слову, в ext3 добавили журналирование не ломая обратную совместимость. Потоки наверно должны быть в разы сложнее для реализации.

Забудь про винду, а? Проблема несколько глубже чем реализация работы с ФС в винде. Смотри - операция открытия файла, как она происходит на лоу левеле, вне зависимости от ОС? Надо найти завись в каталаге, создать дескриптор... Если мы работаем с истино многопоточными файлами - один раз нашли (тут кстати IO нехилове, операция поиска файла весьма ресурсоемка), создали один дескриптор - все, у нас есть инфа о всех потоках. При эмуляции - мы это делаем для КАЖДОГО потока... куча серчей, куча дескрипторов - по одному на каждый поток если быть точным. По капельке тормоза и набегают.

Про ext2/3fs - как не смешно технических ограничений нет. Фактически все сводится к небольшой модернизации формата записи в каталоге - он должен уметь хранить более одной ссылки на i-node. То есть хранить массив ссылок - номер ссылки на i-node в массиве и есть id цепочки данных. Так что потоки в разы проще журнала для реализации. Почему это до сих пор не сделано - я х3.

Прежде чем задавать "задания", вы бы, батенька, всё таки разобрались с вистой, её настройками, NTFS:*, ACL и EA. Извиняюсь, но в вашей голове находится весьма причудливый и похоже забродивший коктейль их этих ингредиентов.

P.S. в RSX-11 версии файлов всегда назывались в_е_р_с_и_я_м_и (в случаях особой тупости - поколениями), а термин "теневые копии" - это совершенно из другой оперы...

P.P.S Судя по всему - познания в области AS/400 столь же "впечатляющи".

Иногда и такое бывает востребовано..

>...поиск и создание дескриптора происходит ОДИН раз при открытие файла, при такой кривой реализации костылем - на КАЖДЫЙ поток.

Объясните как вы одним дескриптором адресуете несколько потоков в ReadFile() и WriteFile(). И главное как вы находите поток по имени без поиска?

>Это бага и этого быть не должно.

Гибкость в настройке стало считатся багой?

> Объясните как вы одним дескриптором адресуете несколько потоков в ReadFile() и WriteFile()

Ну возмите из инклюда структура данных для дескриптора файла и подумайте. Как вариант - вводится понятие текушего потока и соотвественно выбор оного. По умолчанию это поток 0 или 1 - откуда считать привыкли. Это и есть основной поток файла, в котором все хранится по дефолту. То есть если прога ничего не знает о потоках данных она всегда будет работать с ним.

> И главное как вы находите поток по имени без поиска?

Да нет у него имени, есть только порядковый номер. Имя есть у файла.

> Гибкость в настройке стало считатся багой?

Это ни разу не гибкость, хотя бы потому что ACL хранится в потоке и соответственно оно должно быть неразрывно связано с файлом. А у вас такой неразрывной связи никто гарантировать не может.

> Прежде чем задавать "задания", вы бы, батенька, всё таки разобрались с вистой, её настройками, NTFS:*, ACL и EA

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

> в RSX-11 версии файлов всегда назывались в_е_р_с_и_я_м_и (в случаях особой тупости - поколениями), а термин "теневые копии" - это совершенно из другой оперы...

Спасибо я в курсе. Но задачи они решают одни и теже, хотя реализация разная.

Уу, да вы вообще про потоки ничего не знаете. Вот, держите первую ссылку из гугла и просвящайтесь http://www.flexhex.com/docs/articles/alternate-streams.phtml

>You can create or open a named stream exactly the same way you create or open an unnamed stream:

>HANDLE hFile = ::CreateFile("file.dat:alt", ...

>Keep in mind that if the file does not exist, creating a named stream will also create a zero-length unnamed stream.

Название функции выбора текущего потока по номеру или слив защитан.

>>Да нет у него имени, есть только порядковый номер. Имя есть у файла.

E:\>echo main >stream
E:\>echo "This is part1" >stream:part1
E:\>echo "This is part2" >stream:part2
E:\>more <stream
main
E:\>more <stream:part1
"This is part1"
E:\>more <stream:part2
"This is part2"

Хех ...

А может абстрагируемся от того как это сделано в винде и немного подумаем головой? Вообще-то существует более одного метода реализовать потоки данных.

> Падение производительности заметно даже на двух потоках - это когда

... когда система органически неспособна организовать нормальным образом кэширование.

> тут кстати IO нехилове, операция поиска файла весьма ресурсоемка

Чушь. Запусти time find /etc первый раз, и затем еще десять раз. Будешь ОЧЕНЬ удивлен результатом. Конечно, если в твоей системе каждый файл открывается только один раз, и сама система от ребута до ребута живет 15 минут (через 15 минут 3/4 всего что нужно уже лежит в кэше) - то да, поиск по каталогам это "нагрузка".

А есть еще индексы оглавления каталога и прочее, что еще больше нивелирует разницу.

> Если мы работаем с истино многопоточными файлами - один раз нашли (тут кстати IO нехилове, операция поиска файла весьма ресурсоемка), создали один дескриптор - все, у нас есть инфа о всех потоках. При эмуляции - мы это делаем для КАЖДОГО потока... куча серчей, куча дескрипторов - по одному на каждый поток если быть точным. По капельке тормоза и набегают.

А ЧЕМ (открытие многопоточного файла)? отличается от открытия обычной директории (особенно учитывая, что в 90% они даже не нужны)? То, что в винде принято плодить лишние сущности, это и так понятно --- поэтому тормоза и набегают.

> То, что в винде

Эту песенку красноглазые еще про журнал пели, до появления ext3fs :-) Видимо когда наконец-то прикрутят потоки, они начнут ими гордиться и говорить что они их придумали. :-)

Да к слову - вы это... чем дрова ext3 для винды клепать лучше бегите клепайте дрова под exFAT для лиукса. А то вы опять все прощелкали - можете начинать плакать про проклятого монополиста. :-)

>А может абстрагируемся от того как это сделано в винде и немного подумаем головой? Вообще-то существует более одного метода реализовать потоки данных.

Так и запишем: в венде _все_ сделано чиризжопу.

>бегите клепайте дрова под exFAT для лиукса

Может приведете фичи exFAT, отличающие ее от ext3... и так же облажаетесь, как с потоками :)

http://en.wikipedia.org/wiki/ExFAT

Но, честно говоря, ничем не впечатляет :)

Плохо будет, если действительно появится на флешках и портативных устройствах массово. Ведь обратная совместимость как со старыми виндами, так и с другими ОС поломается.

Тем более, что аналогичных ФС - тучи, если я ничего не путаю.