Это правильный драйвер. А вот где нарыть драйвер длинных имен под ДОС? Запарился искать уже, так ничего рабочего и не нашел. Или у меня руки кривые.Цитата:
Сообщение от BS
Вид для печати
Это правильный драйвер. А вот где нарыть драйвер длинных имен под ДОС? Запарился искать уже, так ничего рабочего и не нашел. Или у меня руки кривые.Цитата:
Сообщение от BS
Читать до просветления ;) :rolleyes:Цитата:
Когда я разбивал диск Партишен Меджиком из ДОСа вот что мне показалось: если создать один раздел праймари и в екстендед несколько логических, то на этом я теряю какой-то полезный обьем жесткого диска. Если же создать три праймари раздела и в первый поставить систему, а два других юзать как логические, то потерь нет. Это так или я ошибаюсь? И ваще есть ли смысл создавать праймари разделы когда нужно их количество от 2х до 4х (если больше ясное дело надо делать екстендед)?
Хы. Фикус в том, что по документации Microsoft (всё-тки это они FAT и NTFS делали, нет?) считается, что несколько PRIMARY разделов могут вызывать конфликты и кончаться потерей информации (хотя это вряд ли).
При этом, программы типа BootMagiс, например, обозначают остальные примари-разделы кроме основного, скрытыми (что разумно, вдруг у юзера Win98?), сделав их невидимыми как в DOS, так и в Win98. Вертать взад, если что, будет утомительно, имхо.
Это раз.
А во-вторых, мне каыцца, что потеря 8Мб на винте объёмом 160Гб - это смешно. :)
ну, и в-третьих, может кто-нибудь сказать что-то вразумительное о тех 8Мб, которые остаются "неразмеченными"? ;)
Понял, спасибо! ;)Цитата:
Сообщение от FilippOk
Microsoft наверное сможет? :rolleyes:Цитата:
Сообщение от FilippOk
Насколько я знаю, те 8М, которые остаются неразмеченными, нужны для преобразования диска в динамический, вот их и резервируют на случай "а вдруг юзер захочет преобразовать диск", не спрашивая этого самого юзера.
А потери от использования Extended-разделов вместо Primary составляют 63 сектора (31.5 килобайт) на каждый логический диск в Extended-разделе.
[задумчиво] Хм, очень и очень на то похоже. Спасибо за решение вопроса, sсhuss! :)Цитата:
Сообщение от schuss
А почему именно 63 сектора? :rolleyes:Цитата:
А потери от использования Extended-разделов вместо Primary составляют 63 сектора (31.5 килобайт) на каждый логический диск в Extended-разделе.
Хотя не так уж и важно. Опять же, на 160 Гб потеря 32к за раздел... ххммык. :)
Смотри на Hiren's.BootCD - в 6 версии (последней) точно есть режим работы с поддержкой длинных имен.Цитата:
Сообщение от =RP=Orion
Видимо, это наследие адресации CHS - раздел начинается на следующей дорожке, а на дорожке может быть максимум 63 сектора. Теоретически, может быть и другое число, но я такое встречал только на очень старых дисках, который работали только в CHS-адресации и имели меньше 63-х секторов. А чтобы понять, куда оно девается, достаточно залезть нортоновским дискэдитом на размеченый диск (в режиме просмотра физического диска) и посмотреть. На Hiren's Boot CD дискэдит имеется. ;)Цитата:
Сообщение от FilippOk
Именно.Цитата:
Сообщение от FilippOk
Где можно скачать Hiren's BootCD?
Везде, где находил, только мёртвые ссылки.
В ослосетке есть.Цитата:
Сообщение от Delta_7
Чёт я сам не сообразил. :)Цитата:
Сообщение от schuss
Очень и очень на то похоже.
Contig, который Лёшик посоветовал, в связке с Dikeeper'ом рулят! Пока с ХР геморился, на системнике 17 тысяч фрагментов образовалось... И думаю, че так тормозит все ))
драйвер что HPFS, что HPFS386 при запуске показывает копирайт от МС. так кто кому и чего дал? :)Цитата:
Сообщение от NL
Там же где-то обязан мелькать и копирайт IBM ;)Цитата:
Сообщение от ROSS_Youss
HPFS - 1988, NTFS - 1993?Цитата:
HPFS — High Perfomance File System, файловая система разработанная специалистами Microsoft и IBM на основе опыта IBM по созданию файловых систем MVS, VM/CMS и виртуального метода доступа. Со стороны Microsoft проектом руководил опытный системный программист Gordon Letwin.
http://ru.wikipedia.org/wiki/HPFS
http://en.wikipedia.org/wiki/Comparison_of_file_systems
А как сдружить длинные имена, кириллицу, НТФС и ДОС. Пока получилось 2 вещи:
1. Загрузить NTFSDOSPro в DOS под управлением VC 4.99. В ней есть поддержка длинных имен. Все отображается и читается правильно. Но при копировании русских "длинных" файлов дрова NTFS вываливаются нахрен.
2. Загрузить DOSLFN и NTFSDOS так, чтобы они вообще жили вместе. Однако для DOSLFN не нашел табличку cp1251uni.tbl, поэтому русские имена в VC отображаются непорректно: в частности, в кодировке 866...
Отправной точкой глумления служит Universal Boot Disk v3.6 и NTFS DOS Pro v4 с драйверами NTFS, взятыми из WinXPSP2.
Что посоветуете читару? %)
Подружено в Ultimate Boot CD. Лежит в Яндексе.
Да, действительно. Именно по этому - файлы остаются в том же состоянии, что и до "потери". Т.е. в целостности и сохранности.
С точки зрения ntfs:
"Никакое действие с объектом "файл" не может считается выполненным до тех пор, пока оно действительно не будет выполнено". (change jornal ):)
Чем она еще хороша? Может работать с 2^63-1 байт томами(16 экзабайт).(Проверить невозможно, таких просто не существует.)
Поддерживает EFS шифрование с наследованием, поддерживает систему квот и разграничение доступа, поддерживает механизм многопоточности файла, механизм reparse points(точки повторной обработки), хороший базовый уровень сжатого хранения, журналируемая и очень надежная, и шустро работает с большими файлами как в базовом, так и в динамическом режиме хранения.
Вобщем - переходить на нее надо было году так в 2k без всяких сомнений.
Без проблем с помощью коммерческого\фриварного софта "стороннего разработчика".
Кстати погляди как все просто: ява+любой браузер и уже ext2\3\reiserfs можно почитать.
Или может все-таки *nix попробовать исхитриться перелезть на ntfs? :rolleyes:
Дык чтение что ext3, что reiserfs из винды - не проблема. Проблема с корректной записью на ext3 и reiserfs. Коммерческий софт мы с негодованием отметаем, как неприемлемое решение! :)
Что коммерческие решения для полноценной (кроме загрузки) работы с NTFS из линуха, я прекрасно знаю иодним из них пользуюсь на работе (совершенно легально купленным), но для дома - жаба душит. :)
Элементарно кстати
Win+R в "окошко" cmd <enter>
Уже в консоли cmd
выбрать нужное, написать команду convert с нужными вам ключами и параметрами.<Enter>Цитата:
convert /?
Преобразование файловой системы тома FAT в NTFS.
CONVERT том: /FS:NTFS [/V] [/CvtArea:имя_файла] [/NoSecurity] [/X]
том Определяет букву диска (с последующим двоеточием),
точку подключения или имя тома.
/FS:NTFS Конечная файловая система: NTFS.
/V Включение режима вывода сообщений.
/CVTAREA:имя_файла
Указывает непрерывный файл в корневой папке для резервирования
места для системных файлов NTFS.
/NoSecurity Параметры безопасности для преобразуемых файлов и папок
будут доступны для изменения всем.
/X Принудительное снятие этого тома (если он был подключен).
Все открытые дескрипторы этого тома станут недопустимыми.
Все собссссно... :ups:
Кстати, похоже что nix-community сами как-то не особенно активно решают эту проблему. Уж ему-то ли не знать, как заставить NT писать в ext2/3/Reiserfs и как это решить на основе WinAPI.
Другое дело что, скажем организация доступа к ntfs от Майкрософта - есть тайна за 7-ю печатями и ребятам из проекта ntfs-3g.org действительно пришлось ломать много копий на своих библиотеках под *nix.
А уж обратное движение со стороны Х community должно бы было бы быть более эффективным.
Не совсем. В зависимости от содержимого тома.
К примеру на ntfs томе с множеством маленьких документиков, файликов и програмулечек с утилитками - действует правило:"чем мельче кластер - тем лучше и быстрее доступ".
А на томах, на которых лежит музыка, фильмы, БД, iso? Очевиден ответ: "Чем крупнее кластер - тем большая скорость обработки больших файлов, но большая потеря на фрагментации" Главное - это подобрать разумный баланс. ;)
К сведению - на NTFS мелкие файлики (по моим наблюдениям 700 байт и ниже) вообще не занимают отдельного кластера на диске, так что уменьшать кластер не имеет смысла.
Это справедливо для FAT, но для NTFS этот эффект отсутствует - скорость работы с нефрагментированными данными на NTFS от размера кластера не зависит, так как там совершенно другая система адресации кластеров. А NTFS и фрагментируется меньше, чем FAT, и при равной степени фрагментации работает быстрее.
Кластер 4к считается оптимальным для смешанных данных, когда на диске много и мелких, и крупных файлов.
Не знаю что там в выньапи, поскольку в программировании ничегошеньки не понимаю, но сам при необходимости из-под выньды пишу на свои ext3 разделы разное файло и ничуть не задумываюсь о том, что при этом журналирование идёт лесом, поскольку пишется это всё "как на ext2" - использую Ext2 IFS for windows. Бесплатно и работает :)
Подскажите пожалуйста:
На старом винте по причине нехватки места было включено сжатие для двух NTFS разделов. Купил новый винт, сжатие, есссна, не включал. Переписал информацию со старого винта на новый, но некоторые файлы все равно отображаются синим, как сжатые, и при очистке диска всегда есть что чистить в «Сжатие старых файлов». Как побороть? :rolleyes:
ЗЫ: админы, верните старые смайлы!
Sokill, спасибо :) Это у меня видать просто старые неиспользуемые файлы сжимаются при очистке диска =)
ЗЫ: а вообще есть ли смысл включать сжатие, если места достаточно? Насколько ощутимо падение производительности? (старый винт довольно сильно тормозил у меня, но я это со сжатием не связывал :))
С одной стороны - на мощной машине сжатие не ощущается, но файлы считываются быстрее... с другой - если места много - особо заморачивать ся наверно и не стоит...
У меня когда-то на работе на целероне 300/64 мб/4.3 фуджик WinNT жала файлы (там в основном dbf лежали) довольно прозрачно - в работе этого не ощущалось
Хочу заметить, что ФС NTFS особо ефективна при поиске, т.е. быстрей ищет, особенно это заметно если искать файл в гигаг 200-300 или больше.