Диск не отформатирован после Acronis
 

Добрый день.
Изменил размер дисков с помощью ADD11. У меня на ПК есть 2 ОС Windows XP. Изменения делал с 1ой ОС.
Потребовалась перезагрузка.
После перезагрузки операция по уменьшению диска прошла успешно. Освобожденное место начало добавляться к диску со 2ой ОС.
ADD11 сообщил об ошибках. Было приблизительно "Disk with bad blocks can not be resized."
Загрузился в 1ю ОС. Размер диска увеличился, но Windows сообщает, что он не отформатирован.
Как восстановить диск?

Модели жестких дисков указал в профиле.

"Мыши плакали, кололись, но продолжали еть кактус" (это я об использовании Acronis Disk Destroyer).

Встаньте в DMDE на раздел NEW и нажмите кнопку "Открыть диск". Разверните ветвь $Root. Стрктура каталогов реальна? Можно ли восстановить (из DMDE же) выборочно, на другой диск, файлы из подкаталогов? Восстанавливаются ли правильно (удобно проверять на файлах *.doc, *jpg, *.avi)?

Ну и приведите SMART винчестера.

К сожалению прочитал о побочных эффектах программы уже постфактум.

Я не уточнил. Диск NEW открывается и все файлы вроде бы на месте. Это диск, который я уменьшал.
Перестал открываться тот, который обозначен $Volume 02. Его я увеличивал за счет освобожденного места с диска NEW.
Какой из 4 дисков под $Volume 02 пробовать открыть? И что выбирать, когда после открытия выдает MFT Cluster - нет допустимых значений?

LVitya, по SMART — один нестабильный сектор. Нормальные программы предупреждают об этом до того, как начнут операции, а не после.

Вы не сказали, какие размеры разделов были до, и какие должны были стать после.
По прикидке, кандидатом является $Noname 05. Но это только прикидка, и надо делать полное сканирование в поисках наиболее вероятных кандидатов.

Здравствуйте LVitya,

Насчет восстановления разделов не буду вмешиваться, я уверен, что mwz вам поможет :)

По поводу нестабильного сектора на диске, на всякий случай, после успешного восстановления, запустите extended тест с помощи DataLifeguard (http://products.wdc.com/support/kb.ashx?id=Q3BrCh ) и выложите скрин результатов, так как она исправляет логических ошибок. Альтернативно можете сделать ремап в другую программу или заполнить диск нулями (хотя это удаляет всех данные и занимает время). Имейте в виду, что DLG не показывает RAW значения параметров, а было бы неплохо глянуть на них после ремапа/заполнения нулями.

Еще, рекомендую подумать о бэкап, особенно перед такие операции, да и в принципе, он всегда нужен.

Удачи,
Frost_WD

Честно говоря вообще удивляет как такое поведение попало в код.

Диск NEW уменьшил на 1 ГБ с 296 ГБ до 295 ГБ, а другой диск хотел увеличить с ~23 ГБ до ~24 ГБ.

Кстати заметил еще $Volume 07 с подходящим размером в ветке NEW.

Так что нужно запустить полное сканирование?

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

Так как у вас только один нестабильный сектор, считаю что просто extended тест в DLG разрешить проблему. После него снова выложите СМАРТ статуса.

Как представитель компанию я не могу детально обсуждать неофициальные программы, но в сети и на форуме есть много информация. По любому, у вас есть только один нестабильный сектор и судя по того, что все остальное в СМАРТ в норме, то скорее сего это „софт-бед“

В принципе на мой взгляд, это надо делать полностью. Так как занимает время и удаляет информацию, рекомендую запустить extended тест в DLG или сделать ремап в другую программу. После этого выложите скрин СМАРТ, скорее сего не будет необходимость, заполнят диск нулями.

Вам сама система не необходима – ее можно переустановить в любой момент (как и большинство программы). Обычно бэкап нужен для важной информации – документов и медиа файлов.

Удачи,
Frost_WD

Если Extended Test, который рекомендовал Frost_WD, не поможет — можно попробовать сделать точечную перезапись нестабильного сектора в DMDE.

Запускаете диск на проверку в утилите Victoria, режим Read+Ignore. Записываете номера тех секторов, на которых спотыкается Victoria (у вас по идее должен быть один такой).
Округляете вниз до ближайшего кратного восьми (например, при плохом секторе 1007, показанном в Victoria, его надо округлить до 1000, а при плохом 1008 – его и оставить).

Открываете в DMDE диск как физический и закрываете верхнее окно с разделами.

Сервис -> Копировать секторы...

Копирование на примере нестабильного сектора 1007:



Выберите в качестве и источника, и приёмника этот ваш диск, начальный сектор и там и там – тот, который уже округлён (здесь 1007, т.е. округляется до 1000), число секторов источника – 8 (конечный сектор тогда вставится сам; как видите, здесь нестабильный сектор 1007 вошёл в охватываемый диапазон из 8 секторов как последний).

Ещё раз убедитесь в том, что диск-источник и диск-приёмник один и тот же, и что начальные сектора источника и приёмника совпадают; эти два параметра являются "болевыми", и несовпадения в этих местах приведут к порчи части информации на диске-приёмнике. Нажмите Ок. В случае появления сообщения об ошибке копирования – игнорировать его (т.е. всё равно продолжить).

И так с каждым проблемным. А если проблемные сектора лежат близко друг к другу – можно охватывать их в одной операции (как охватывать – думаю что будет понятно из следующего абзаца).

А вообще рекомендуют несколько расширить диапазон перезаписываемых секторов как снизу, так и сверху, примерно на три-десять групп по 8 секторов: чтение и обратная запись "здоровых" секторов ни к каким проблемам не приведёт (как и ошибка с выбором диска при условии, что источник и приёмник, а также начальный сектор чтения и записи одни и те же), но заодно будет проверена зона вокруг нестабильного сектора.

Когда-то я сам для себя через форточку этот метод открыл, но теперь обнаружил, что мощная HDAT2 отлично умеет работать с 4KiB секторами...

LVitya, если не получиться извести bad, как предлагал mwz :) , --- хотя должно получиться..., то напустите на устройство HDAT2...

Преимущество утили в большой информативности её рапортов. --- Сами увидите.

ЗЫ Одно "неудобство" (для тех, кто боится DOS... ), что надо её из-под DOS запустить. Но это как раз её достоинство.

ЗЫ По-любому, после лечения бэда покажите актуальный рапорт SMART...

Tau_0, так сначала надо попытаться полечить бэдсектор, а уже потом восстанавливать раздел?

Frost_WD советовал лечить после восстановления

Бэды есть основной источник логических ошибок, а для акрониса это справедливо вдвойне... --- "Гладко было на бумаге, да забыли про овраги..."

Я считаю, что нужно начинать именно с избавления от бэдов . Конечно, профессиональные специалисты DR работают с комплексом PC−3000. И их подход к проблеме будет совсем иным... Но нам с нашими подручными средствами надо начинать с этого...

Вроде бы вылечился бэдсектор.
Что делать дальше?

Похоже, что вылечился..., а то, что атрибут ID=C6 показывает на один сектор, нескорректированный в оффлайне, должно со временем пройти (после того, как хард WD выполнит все self-tests).

Вот тут я не могу придумать ничего лучше, как выполнить полное сканирование харда...

Как всегда, Акронис создал расширенный раздел, но в нём только один целый логический раздел… Поэтому запустите полное сканирование харда, а по окончании лог (текстовый файл) сохраните и приложите к ответу…

Просканировал, но не могу прикрепить zip файл с отчетом. Пишет недостаточно места.
Выложил пока что на внешний ресурс.
https://dropmefiles.com/AmmQ2

А не могли бы Вы выложить на rghost.ru...???... --- С этим ресурсом у меня более-менее..., а с другими заморочка.:(

Вот выложил
http://rgho.st/6yVgFG4LR

LVitya
Если запускал акронис из под винды, можешь найти логи его действий и выложить в архиве?
В 7-ке они лежат в Program Data\acronis\дальше какие то подпапки и там файлы с расширением log
Скорей всего, в ХР это будет где то в Application Data\Acronis

yab, прикладываю. Не знаю как они помогут, не вижу там интересной информации.

Час от часу не легче...:I
--- Rghost выдаёт: --- 403

вам запрещено это действие, этот файл приватный и ваш ключ неправильный

Tau_0, вроде бы уже работает.

LVitya
Была надежда что там будут какие то подробности проделанной работы или причины ошибки, но увы и ах.
Впрочем, похоже на то, что сбойнуло на записи $MFTmirr.
Нужно бы глянуть в содержимое секторов 578998735 и 612574599-612574600

yab, вот скинул http://rgho.st/8TqKxGfjc

LVitya
Ага, скачал - без поллитра не осилить. ;)
PS. Почисть переполненные личные сообщения.

Полазить по файловым записям можно и нужно, но это потом, --- если не так страшно акронис накуролесил...
Ага, посмотрел…
И Вы посмотрите, пока без бутылки :).
См. картинку во вложении…

В DMDE опять запустите полное сканирование. Но сканировать ничего не надо, а надо загрузить старый (сохранённый ) лог.
После чего откройте том $NTFS1 и в браузере DMDE откройте $Root и пошарьте там, --- посмотрите на нужные Вам файлы и папки. Навскидку скопируйте несколько файлов на любой сторонний носитель, например, на флешку.

Затем уже в Windows откройте эти файлы, проверьте их корректность….
NTFS на томе $NTFS1 порушена, а вот насколько, --- неясно… Хотя пог поиска на первый взгяд выглядит прилично…

Добавлено
=======
Написал правильно, но по небрежности,:( на картинке выделил не NTFS1, а NTFS0 (с ним всё в порядке)...
Есно Вы NTFS1 выделяете и открываете...

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

LVitya,
В DMDE выделяете Дополнительный/Расширенный/Extended раздел в красной рамке, и удаляете его. --- Ну не люблю я расширенные разделы… --- Да и сто лет он здесь не нужен.

Затем вставляете раздел New в синей й рамке и вставляете его как Основной раздел.

См. картинку…
Перезагружаете машину, смотрите… И вновь показываете картинку Разделы диска… из DMDE.

Ну и картинку из Управления дисками покажите --- Она не повредит…
Структура может быть правильной, а содержимое файлов нет. --- Акронис может поверху написать…

Tau_0, почитал про эти операции.
Переживаю чтобы эти действия не навредили.
Насколько я понял, если удасться успешно восстановить, и я захочу разбить диск NEW на диски поменьше, то я смогу создать только еще 2 основных раздела. Думаю мне этого хватит, главное чтобы ничего не случилось с данными.

Удаление расширенного раздела нужно, чтобы проще было восстановить поврежденный раздел. Я правильно понял?

Мне так проще... А информация не пострадает (Ваша ценная информация вне диапазона секторов NEW), она и так пока недоступна..

Пока меня интересует станет ли доступен NEW...???... -- По идее ничего ему мешать не будет... А сейчас, второй логический диск в расширенном разделе своей дурной гголовой (происки акрониса...), ему хвост прищемил...

Tau_0, наконец-то сделал. Извините за долгие интервалы: мало времени после работы.
NEW доступен через проводник. А испорченный диск пропал.

Вернём, но пока испорченным...

Выделяете раздел $Volume 09 в синей рамке и вставляете его как Основной раздел. Обратите внимание на то, что раздел начинается в LBA = 578 998 735.
См. картинку…
Сравните его с началом тома NTFS 1, что нашли при глубоком сканировании. --- Увидите, что мы не ошиблись. Правда, что-то нехорошее в ФС NTFS есть…
Поэтому в Упралении дисками он должен появиться как RAW…

Снова покажите картинки из DMDE и Управления дисками…
Да, в DMDE отметьте чекбокс GiB. Это чтобы размеры разделов в DMDE и Управлении дисками совпадали…

Ну, а теперь пришлите мне
100 секторов, начиная с LBA = 612 574 599
Это начало MFT…
8 секторов, начиная с LBA = 612 574 895
Это зеркало $MFTMirr… --- Громко сказано, там только 4 файловые записи…

Tau_0, вставил диск. Он появился в проводнике и открывается. Там видны файлы и папки.
Прикрепляю все как просили.

Чудны дела твои, Господи... :angel:
Я был уверен, что как RAW откроется... --- В DMDE у него не виден индикатор F...
Этот том был придавлен другим логическим диском в расширенном разделе

Я малость впопыхах и подзабыв… писал ===>
Это касалось именно $Volume 09, а не NEW. --- Думал тогда правильно, но написал некрасиво… Но мы расширенный раздел убрали вместе с вредным $Volume 02, и перекрывать некому…

Повторяюсь. ===>
Для меня странно, что раздел Win2011 не RAW, и том доступен…
Может Вы или Windows на него чекдиск напускали…???...
Пришлите опять картинку Разделы диска… из DMDE, плз.
В дампы с файловыми записями я пока не полезу (муторное дело), а том и так доступен…

ЗЫ Вы пока, на всякий пожарный, скопируйте ценное на другой носитель, --- 22 GiB это не так много…

Нет, чекдиск не запускался.
Прикрепил.
Так что уже можно пользоваться?

Пользоваться томом пока нельзя… ---- Не совсем там хорошее в ФС DMDE углядел (индикатор F не виден…).
Поэтому с Live CD загрузитесь. Там Windows спокойный и на том просто так не полезет…
Пуск ===> Выполнить ===> cmd
В командной строке набираете ===>
Chkdsk X: (без ключей), где X: реальная буква диска болезного тома

Выделяете по copy/past текстовый рапорт чекдиска и показываете…

C:\Documents and Settings\Vitya>Chkdsk G:
Тип файловой системы: NTFS.
Метка тома: Win2011.

ВНИМАНИЕ! Параметр F не указан.
CHKDSK выполняется в режиме только чтения.

Проверка файлов (этап 1 из 3)...
Проверка файлов завершена.
Проверка индексов (этап 2 из 3)...
Проверка индексов завершена.
Проверка дескрипторов безопасности (этап 3 из 3)...
Проверка дескрипторов безопасности завершена.
CHKDSK проверяет журнал USN..
Завершена проверка журнала USN

23069304 КБ всего на диске.
22285004 КБ в 272402 файлах.
105304 КБ в 20472 индексах.
4 КБ в поврежденных секторах.
448664 КБ используется системой.
65536 КБ занято под файл журнала.
230328 КБ свободно на диске.

Размер кластера: 4096 байт.
Всего кластеров на диске: 5767326.
57582 кластеров на диске.

Помотрел рапорт чекдиска, --- почти нормально...

А теперь запустите чекдиск в режиме исправления ошибок...
Chkdsk G: /F

После прогона чекдиска покажите рапорт утилиты и Разделы диска из DMDE.

А что подразумевается под почти?
Это что то типа "почти беременна"?

====>

В отчёте нет сообщения, что ВСЁ нормально... ===>
Вот и ВСЁ...
Я гораздо более страшные рапорты чекдиска видал. Но нужно, чтобы последний рапорт был гладким...

ЗЫ Вы бы лучше не бутылкой разбирались, ===>
а предложили иное конструктивное решение, а то как навязчивый троль/банный лист приклеились...

ЗЗЫ А попить мы тоже любим и умеем. Но умеем и не только это... :gigi::gigi::gigi:

Стандартное сообщение, констатирующее содержимое $BadClus.
Новые бэды выявляются после использования ключа r

А вот это правильно. Ну хоть что то реально полезное, вместо псевдонаездов хвостов на головы и прочего.

Вообще то это русская народная шутка. Разбираться с метафайлами надо по трезвому. И это было сделано и причина найдена, и много что ещё. И это в отличие от .Хотя дело то не в муторности, а в неумении читать и анализировать.
И да, после правок чекдиска, заветная F не появится.

$BadClus - это обычный sparse-файл. Если бэд-кластеров нет, то файл имеет один sparse-фрагмент размером с весь раздел.

Да плевать на этот метафайл --- это обычная помойка... Он не критичен для NTFS.
В том же WinHex достаточно затереть его файловую запись (обычно два сектора...). И Windows создаст новый, что целка нетраханая... --- Софт-бэддов нет.

--- Тут другого опасаешься...

Tau_0
Типа сумничал.
Только к чему цитировать содержимое букваря, если речь шла о другом.
В муторные файлы загляни что ли. :yes:

Кстати, не всегда.

Если бэд кластеров нет, то всегда... В этом и хитрость этого метафайла --- весьма изящно решено...
Не смотрел, и смотреть не буду (пока оно мне без надобностев..), чтобы не спиться...:gigi::gigi::gigi:
--- В MFT сотни тысяч файлов.

ЗЫ Я что-то не усмотрел ни здесь на зоне, ни на кибере, чтобы Вы хоть одну задачу как-то порешали...

Отсутствие реального опыта, да и лень никогда к хорошему не приводит.
Хинт. Уменьшенный в размере том может иметь старые данные этой записи.

Ну зачем тулить очередную отмазку?

А это что показатель или как?
Вообще то здесь минимум две решены, в полном обьёме.

C:\Documents and Settings\Vitya>Chkdsk G: /F
Тип файловой системы: NTFS.
Метка тома: Win2011.

Проверка файлов (этап 1 из 3)...
Проверка файлов завершена.
Проверка индексов (этап 2 из 3)...
Проверка индексов завершена.
Проверка дескрипторов безопасности (этап 3 из 3)...
Проверка дескрипторов безопасности завершена.
CHKDSK проверяет журнал USN..
Завершена проверка журнала USN

23069304 КБ всего на диске.
22284972 КБ в 272397 файлах.
105304 КБ в 20469 индексах.
4 КБ в поврежденных секторах.
448664 КБ используется системой.
65536 КБ занято под файл журнала.
230360 КБ свободно на диске.

Размер кластера: 4096 байт.
Всего кластеров на диске: 5767326.
57590 кластеров на диске.

LVitya
G это системный раздел той системы с которой запустился?
Сделай ещё раз дамп 612574599+50 и 579049055+10, а ещё бы лог поиска NTFS (достаточно логического раздела).

Давно я это счастье посмотрел…
И чекдиск там ничего не исправил…:(

Файловая запись ID=0, $MFT должна быть нехороша… И в зеркале такая же ерунда…
Надо бы по Update Sequence (массиву корректировки) полазить и посмотреть. Но сразу поленился а сейчас некогда. --- Уезжаю на несколько дней и буду только в понедельник.

Файловая запись ID=16 BAAD, --- и Бох с ней…
До посинения по записям MFT можно лазать…

Да ладно, и что толку.

Ну так дамп то был сделан до работы чекдиска.

И действительно "Слона то ты и не заметил". Это типа как придраться к соринке в огромной луже грязи.

С таким же успехом можешь полазить по Эвересту. :lol:

Я запускался с системы, которая лежит на диске C:\
Пока что только дампы, так как поиск долго идет.

Меня тоже не будет до вторника.

Пробовал на ХР запускать чекдиск и заметил что при проверке любого несистемного диска в конце выводится сообщение что ошибок не обнаружено, а на системном такого нет. Поэтому думал что зависит от того какой раздел проверяется.
Поэтому даже не знаю что и сказать.

В принципе достаточно и дампов - видно что чекдиск внёс изменения.

А я вот никаких изменений не заметил…:

1. Как DMDE в окне Разделы диска находил что-то нехорошее в ФС тома $Volume 02, так и после чекдиска индикатор F не появился…

2. Но главное, --- меня ставит в полное недоумение первая файловая запись MFT ID=0. В этой записи отсутствует атрибут типа File Name. Это атрибут всегда должен быть резидентным и имя должно быть $MFT…

А так эта запись MFT вполне корректна и целостность её не нарушена….

Я не знаю, --- как такое могло получиться. Но так есть.
И почему чекдиск это спокойно пропускает...???...

LVitya, эти мои размышлизмы носят скорее академический характер…

Вам нужно:
========
1. Зарезервировать данные на сторонний носитель.

2. Разбить хард на нужное количество и размер разделов средствами Windows, --- не используйте никаких акролнисов и подобных утилит.
ЗЫ Радуйтесь, что ещё легко отделались и не потеряли данные…

3. Инсталлировать Windows и нужные программы.

4. Вернуть данные из резерва…

Вот, примерно, так Вам надо поступить…

Разве это неожиданно? :)
А чекдиск считает что он может быть и не резидентным. Да и сама система, т.к. в противном случае том бы не открылся и до исправлений чекдиска.

Покажите в рапортах чекдиска, где есть хоть какая-то обмолвка об исравлениях хоть чего-нибудь...

Tau_0
А он должен писать обо всех? К тому же некоторые исправления система может сделать сама и без сообщений - например, можно затереть зеркало, и оно самовосстановится. И без всяких чекдисков.
Могу предложить вернуться в прошлое и попробовать осмыслить имеющееся.
Начать с лога поиска и с дампа 0-вой записи, которая была выложена давно - http://forum.oszone.net/post-2642438.html#post2642438
И в ней достаточно данных чтобы увидеть что третий фрагмент отсутствует в результатах поиска, при этом в результатах поиска эти записи фигурируют в другом месте. А в последних дампах видно что всё уже на нужном месте.

Так ведь самовосстановится без чекдиска...

Наметился прогресс?

Милай ты мой..., ещё несколько лет назад я удалял некоторые некритичные метафайлы типы битовой карты или $BadClus. Система их спокойно восстаналивала без чекдиска...

ЗЫ Что до файловой записи MFT, то имя файловой записи не является обязателным типом... --- Вот и проходит без него.. Но из принципа поискал в сети. --- Пишут, что File name всегда резидентен. Да и нет никаго смысла такую крохотульку нерезидентной делать...

Но ведь официальной спецификации NTFS нет, а есть только то, что при реинженеринге раскопали энтузиасты Linux-group...

Ты уж определись является или нет. :)
Сам себе противоречишь и бубнишь какую то ересь.
Может лучше промолчать, или вообще изучить то, что предложил?

Умник или чванливый невежа...:gigi::gigi::gigi:
Прочти и малость извилиной пошевели... ===>

Attribute - $FILE_NAME (0x30)

&

Записки исследователя NTFS

Tau_0
Более чем на копипасту способностей не хватает?
Я понимаю что тебе нечем шевелить, поэтому разжёвываю.
30-й атрибут в записи есть - просто он описан немного в другом виде.
Правильно это или нет, и кто так сделал - вопрос вторичный. Но раз раздел работает, то это о чём то говорит. По крайней мере для тех кто может воспринимать реальность а не витать в облаках "исследователей" (компетентность некоторых вызывает сомнения).

Зри картику в форматном просмотре файловой записи ID=0. --- Покаж мя, где твоя увидела Attribute type = 30...???...

Tau_0
Накопи знаний и научись пользоваться мозгами ими и нормальными программами.

То есть лучше не пробовать запускать Windows на этом диске?

С Windows то более-менее ничего...
Но.. ===>
Вас не устраивало текущее разбиение диска на разделы, и Вы решили его перекромсать с помощью акрониса... --- По целому ряду причин такой подход очень плох, несмотря на это внешнюю привлекательность...

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

Вроде бы как-то второй раздел стал доступен, но кое-что мне в нём не нравится...

Я с самого начала убеждап Вас зарезервировать (на всякий случай) данные с восстановленного раздела. Видно, что не первый раз Вы хард перекраивали... И пока отделались лёгким испугом... --- Так пока Вам просто везёт...

Если теперь текущее разбиение Вас устравает (...???...), --- оставляйте как оно есть. Но в этом есть свой риск...

yab, мозгами пользуюсь, как умею... А вот насчёт нормальных программ ты рассмешил...:gigi::gigi::gigi: --- Видно, что никогда не кодировал...
Чтобы правильно распарсить файловую запись много мозгов не надо, --- тут это просто и незамысловато из определения ФЗ делается...
А DMDE и WinHex --- достойные дисковые редакторы...

Предлагаешь поверить на слово в эту пугалку?

Бзик с расширенным уже был замечен.
Про мины пока непонятно, а что это за бзик?

Это заметно. Вопрос лишь в том или не умеешь пользоваться, или нечем пользоваться.
И особенно это актуально в свете
У тебя и на это способности нет.

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

Будем считать, что системному диску от этого хуже не стало. --- Всё дело в том, что происходило с медиа диском, когда у него место забиралось… --- Очень серьезные вещи на такой перестройке происходили….

Далее я дам краткий ответ своему оппоненту, из него Вы многое поймёте…

По поводу Расширенного/Дополнительного/Extended раздела.
Данную возможность сделали для того, чтобы можно было создать более четырёх разделов. Оно бы и нечего, но ведь это цепочка или однонаправленный список. Если случится что-то нехорошее с EBR/AMBR одного из разделов, то цепочка порвана и следующие разделы в контейнере становятся недоступными…. Это не сложно отремонтировать, но надо уметь…

Но не это главное. Все партмагоиды: PM, Acronis, …, etc… очень нехорошо преобразуют Primary/Основной раздел в логический диск в расширенном разделе. --- Они сдвигают левую границу раздела, а это чревато очень нехорошими последствиями…

Если бы мне понадобилось из Основного раздела сделать расширенный, то я бы сделал это так. ---- Перед расширенным разделом безопасно откусил 63/2048 секторов с конца раздела предшественника и там просто и незамысловато посредством дискового редактора создал бы EBR/AMBR для контейнера/Расширенного раздела.

Но Акронис и другой партмагоид действует иначе. Он сдвигает весь раздел/том, и тут начинается… --- Пересылаются пересчитываются файловые записи и DataRuns --- это огромный кусок работы…. И если что-то пошло не так (сбойные секторы или пропало питание, или…), то приехали --- ни два, ни полтора. --- Получили партмагоидное смещение, которое в теории ещё объяснимо, но на практике попробуй расхлебай…
Вот и у LVitya Акронис начал создавать в контейнере новый логический раздел в расширенном диске, да загнулся… Я потому и удалил контейнер, что он перекрывал старый логический диск. Этот диск тоже дитя Акрониса (достаточно посмотреть на местоположение MFT), и нельзя сказать, что он всем хорош. --- Вполне может быть так, что по файловой системе вычитается сосем не то….

В этом и мина… --- Лучше зарезервировать данные и пересоздать/переформатировать том…

Это только вкратце…

Давай без этих азбучных "умняков".
И что? Есть обратная польза - достаточно "дёрнуть начало клубка" расширенного раздела и все разделы на месте.
Типа для восстановления основных разделов умения нужно?
Прям таки все? Может лучше попробовать а не пороть чушь?
Где?
А можно конкретно показать перекрытие?
Да ладно. Акронис располагает метафайлы в самом начале тома. А тут начало дальше чем винда располагает.
Если суммировать все мои ответы - мина на самом деле существует лишь в мутном сознании.
Это хорошо что коротко, а то даже страшно представить ещё бОльший поток мутного сознания. :)

Ага, это почти тоже самое, что при последовательном соединении нудно искать перегоревшую лампочку...

Запросто. См картинку...

Записи MFT пересчитываются ВСЕ, --- реперная точка начала раздела меняется. А вот сами ФЗ и экстенты могут пересылаться, а могут и не пересылаться. --- Зависит от того, куда влево/вправо и как далеко акронис левую границу раздела смещает. Но в любом случае на перемещение левой границы раздела табу...

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

Отсюда я и делаю вывод, что раньше том уже перкраивался...

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

Хочешь сказать что в случае первичных разделов всё видно и понятно даже такому как ты? :)
Обычный логический в расширенном. С отступом как и положено. Где перекрытие?
Вообще то писалось про то, что не все делают так тупо как акронис - то есть оставляя раздел на месте и оперируют лишь таблицами разделов.
То есть он раньше был ещё настолько меньше?
Вообще то это было обычной шуткой. И если ты пытаешься меня потролить, то это лишний раз подтверждает то, что ты сам понимаешь как облажался - с разделами, муторными записями и т.п..
Даже с советом перефоратить всё - у человека с первым разделом всё в порядке. И переставить винду - при том что даже не было попытки её запустить.

Вообще то было, как и в другом случае (там тоже присутствовали "перекрытия" :) . Если это непонятно, то это не моя проблема.

Кстати, в другом случае, так и остался без ответа http://forum.oszone.net/post-2643759.html#post2643759
Что так слился по тихому? А как до этого обвинял меня в невежестве. :lol:

--- В Караганде... Сам расширенный перекрывает нужный $Volume 09. А замороки в расширенном DMDE красным крестом пометил, --- глаза разуй... Но мне расширенный был ни к чему, --- лишние ненужные сопли...
Нет не ВСЁ в порядке...
--- Раздел слишком далеко начинается начинается в секторе 16 135, а не в секторе 63/2048. Причём начинается в расширенном разделе, --- ни один инстаппятор так не поставит. --- Отсюда делаю вывод, что и здесь Акронис лапу приложил и двигал вправо левую границу раздела... А это нехорошо, --- на это табу...

Выходит, что так...

Да нужен ты мне... :gigi::gigi::gigi: --- Это как раз ты с своими ремарками лезешь под руку и под ногами путаешься...
ЗЫ Я никогда не влажу со своим суждением, если кто-то начал решать проблему по-своему... Вмеешиваюсь только тогда, когда решение застопоривается или что-то, на мой взгляд, слишком опасное предлагается...

Добавлено
========
Да что ты городишь...???... Это TS "слился по тихому" и пропал... А я в пустоту писать не намерен, и на словоблудие с тобой своё время тратить не намерен...

Теперь понятна твоя боязнь логических разделов в расширенном - ведь ты не понимаешь что они находятся в границах расширенного.
Чтобы было понятнее - твои обвинения сродни обвинения кастрюли в том что внутри неё борщ (или наоборот). :lol:
Да у огромного числа пользователей так, причём и в более экзотических местах. Нестандартно - да, но ведь это не смертельно. И не инсталятор это делает - ты кстати видимо не понял что речь идёт о втором физическом диске.
Это мог и не акронис сделать.
Ну это твой бзик. И что то ты слишком часто пишешь табу - узнал для себя новое слово?
А если нет, то что тогда?
Ну так и я не сразу отвечал. Тем более что начались опасные удаления-вставки и последующие опасные твои советы.
Вообще то он убедился в некомпетенции ответчика и уже решил свою проблемку.
Ух ты. Вякать по поводу моей некомпетенции время есть. Незаслужено брехать про программу тоже. А ответить за свой (бакланский) базар - сразу занят?

Не собираюсь с тобой на фене ботать...
Прочти ===>
См. на хоботе пост Antech написано 13.02.2010 20:35 в теме
Проблемы с объединением/разбитием/после объединения/разбития диска на разделы (Страница 22)

Я бы с тобой пообщался на техническом, но ты же нулевой в этом плане.
И приведенная копипаста это подтверждает, при том что она вообще не по тем вопросам о каких напомнил.
Тем не менее.
Любое написанное надо читать с пониманием.
Там написано нельзя, но не вообще (как у тебя табу) а с точки зрения безопасности.
4-й пункт вообще неактуален - винда это делает безопасно.
5-й помягче твоего табу, но изначально неправильно сформулирован. Правильнее сказать "нельзя изменять тем, что может изменить границы раздела". Кстати, я уже упоминал что есть программы, которые не трогают раздел при преобразовании - и такие были и ранее 2010 года.

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

Сегодня попробовал загрузиться с восстановленного диска.
Загрузка прошла нормально. Вкладки в браузере открываются. Работал в этой Винде не долго. Но кое-какие странности все таки заметил.
Др. Веб пишет, что не может найти файл с лицензией. Винда выдала, что нашла новое оборудование и установили его, хотя я ничего не подключал.

LVitya
Ключ файла можно поискать. Ну а новое оборудование - так это тома с изменёнными размерами.
Да и в таких расколбасах обычно речь идёт о восстановлении данных.

Попробую поискать. Вроде где-то должна быть копия.

Нужные данные перекинул на другой диск.

Так что буду продолжать пользоваться этой Виндой. А по мере возможности готовить место для новой.

В принципе диск работает и даже Винда загрузилась, так что всем огромное спасибо.

Под искать подразумевалось на разделе.
То есть есть ли он в нжном месте или нет. Если есть то его корректность.
В любом случае, если будешь работать с этой виндой, то сделай хотя бы проверку системных файлов, если какой то софт позволяет сделать восстановление себя, то сделай такое.
А для исклчения раширенного атрибута и фрагментации поступи так, как я писал ранее в привате.