Показать полную графическую версию : [решено] Диск не отформатирован после Acronis
Tau_0
Типа сумничал.
Только к чему цитировать содержимое букваря, если речь шла о другом.
В муторные файлы загляни что ли. :yes:
файл имеет один sparse-фрагмент размером с весь раздел. »
Кстати, не всегда.
Кстати, не всегда. »
Если бэд кластеров нет, то всегда... В этом и хитрость этого метафайла --- весьма изящно решено...
В муторные файлы загляни что ли. »
Не смотрел, и смотреть не буду (пока оно мне без надобностев..), чтобы не спиться...: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 (достаточно логического раздела).
Сделай ещё раз дамп 612574599+50 »
Давно я это счастье посмотрел…
И чекдиск там ничего не исправил…:(
Файловая запись ID=0, $MFT должна быть нехороша… И в зеркале такая же ерунда…
Надо бы по Update Sequence (массиву корректировки) полазить и посмотреть. Но сразу поленился а сейчас некогда. --- Уезжаю на несколько дней и буду только в понедельник.
Файловая запись ID=16 BAAD, --- и Бох с ней…
До посинения по записям MFT можно лазать…
Давно я это счастье посмотрел… »
Да ладно, и что толку.
И чекдиск там ничего не исправил… »
Ну так дамп то был сделан до работы чекдиска.
Файловая запись ID=16 BAAD, --- и Бох с ней… »
И действительно "Слона то ты и не заметил". Это типа как придраться к соринке в огромной луже грязи.
Надо бы по Update Sequence (массиву корректировки) полазить и посмотреть. »
До посинения по записям MFT можно лазать… »
С таким же успехом можешь полазить по Эвересту. :lol:
G это системный раздел той системы с которой запустился? »
Я запускался с системы, которая лежит на диске C:\
Сделай ещё раз дамп 612574599+50 и 579049055+10, а ещё бы лог поиска NTFS (достаточно логического раздела). »
Пока что только дампы, так как поиск долго идет.
Уезжаю на несколько дней и буду только в понедельник. »
Меня тоже не будет до вторника.
Я запускался с системы, которая лежит на диске C:\ »
Пробовал на ХР запускать чекдиск и заметил что при проверке любого несистемного диска в конце выводится сообщение что ошибок не обнаружено, а на системном такого нет. Поэтому думал что зависит от того какой раздел проверяется.
Поэтому даже не знаю что и сказать.
Пока что только дампы »
В принципе достаточно и дампов - видно что чекдиск внёс изменения.
В принципе достаточно и дампов - видно что чекдиск внёс изменения. »
А я вот никаких изменений не заметил…:
1. Как DMDE в окне Разделы диска находил что-то нехорошее в ФС тома $Volume 02, так и после чекдиска индикатор F не появился…
2. Но главное, --- меня ставит в полное недоумение первая файловая запись MFT ID=0. В этой записи отсутствует атрибут типа File Name. Это атрибут всегда должен быть резидентным и имя должно быть $MFT…
А так эта запись MFT вполне корректна и целостность её не нарушена….
Я не знаю, --- как такое могло получиться. Но так есть.
И почему чекдиск это спокойно пропускает...???...
LVitya, эти мои размышлизмы носят скорее академический характер…
Вам нужно:
========
1. Зарезервировать данные на сторонний носитель.
2. Разбить хард на нужное количество и размер разделов средствами Windows, --- не используйте никаких акролнисов и подобных утилит.
ЗЫ Радуйтесь, что ещё легко отделались и не потеряли данные…
3. Инсталлировать Windows и нужные программы.
4. Вернуть данные из резерва…
Вот, примерно, так Вам надо поступить…
А я вот никаких изменений не заметил…: »
Разве это неожиданно? :)
Это атрибут всегда должен быть резидентным и имя должно быть $MFT… »
А чекдиск считает что он может быть и не резидентным. Да и сама система, т.к. в противном случае том бы не открылся и до исправлений чекдиска.
и до исправлений чекдиска. »
Покажите в рапортах чекдиска, где есть хоть какая-то обмолвка об исравлениях хоть чего-нибудь...
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) (https://flatcap.org/linux-ntfs/ntfs/attributes/file_name.html)
&
Атрибут $FILE_NAME всегда резидентен. Он служит для двух функций. Во-первых, хранит имя файла в записи MFT, причем атрибутов $FILE_NAME у файла может быть несколько (NT эмулирует различные подсистемы DOS и POSIX, в том числе и на уровне файлов). Для MS-DOS атрибут будет хранить имя в формате 8.3, для POSIX символы имени файла с учетом регистра и стандартное имя для Win32 подсистемы. Один атрибут может содержать имя сразу для двух подсистем (обычно, 3 – Win32|DOS, если имя влезает в формат 8.3). Во-вторых, атрибут используется для организации индекса в структуре каталогов, где он выступает как индексный элемент. Заметьте, ошибочным является утверждение, что индексы дублируют только один $FILE_NAME для файла, как раз наоборот, если файл имеет в записи MFT один $FILE_NAME для DOS и другой для Win32, то оба они будут дублироваться и в индексах.
Записки исследователя NTFS (http://citforum.ru/operating_systems/windows/ntfs/3.shtml)
Tau_0
Более чем на копипасту способностей не хватает?
Я понимаю что тебе нечем шевелить, поэтому разжёвываю.
30-й атрибут в записи есть - просто он описан немного в другом виде.
Правильно это или нет, и кто так сделал - вопрос вторичный. Но раз раздел работает, то это о чём то говорит. По крайней мере для тех кто может воспринимать реальность а не витать в облаках "исследователей" (компетентность некоторых вызывает сомнения).
30-й атрибут в записи есть - просто он описан немного в другом виде. »
Зри картику в форматном просмотре файловой записи ID=0. --- Покаж мя, где твоя увидела Attribute type = 30...???...
© OSzone.net 2001-2012
vBulletin v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.
Available in ZeroNet 1osznRoVratMCN3bFoFpR2pSV5c9z6sTC