PDA

Показать полную графическую версию : [решено] Диск не отформатирован после Acronis


Страниц : 1 2 [3] 4

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

файл имеет один sparse-фрагмент размером с весь раздел. »
Кстати, не всегда.

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

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

yab
22-06-2016, 22:03
Если бэд кластеров нет, то всегда... »
Отсутствие реального опыта, да и лень никогда к хорошему не приводит.
Хинт. Уменьшенный в размере том может иметь старые данные этой записи.

Не смотрел, и смотреть не буду (пока оно мне без надобностев..) »
Ну зачем тулить очередную отмазку?

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

LVitya
22-06-2016, 23:52
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 кластеров на диске.

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

Tau_0
23-06-2016, 08:11
Сделай ещё раз дамп 612574599+50 »
Давно я это счастье посмотрел…
И чекдиск там ничего не исправил…:(

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

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

yab
23-06-2016, 10:37
Давно я это счастье посмотрел… »
Да ладно, и что толку.

И чекдиск там ничего не исправил… »
Ну так дамп то был сделан до работы чекдиска.

Файловая запись ID=16 BAAD, --- и Бох с ней… »
И действительно "Слона то ты и не заметил". Это типа как придраться к соринке в огромной луже грязи.

Надо бы по Update Sequence (массиву корректировки) полазить и посмотреть. »
До посинения по записям MFT можно лазать… »
С таким же успехом можешь полазить по Эвересту. :lol:

LVitya
25-06-2016, 14:33
G это системный раздел той системы с которой запустился? »
Я запускался с системы, которая лежит на диске C:\
Сделай ещё раз дамп 612574599+50 и 579049055+10, а ещё бы лог поиска NTFS (достаточно логического раздела). »
Пока что только дампы, так как поиск долго идет.

Уезжаю на несколько дней и буду только в понедельник. »
Меня тоже не будет до вторника.

yab
25-06-2016, 16:02
Я запускался с системы, которая лежит на диске C:\ »
Пробовал на ХР запускать чекдиск и заметил что при проверке любого несистемного диска в конце выводится сообщение что ошибок не обнаружено, а на системном такого нет. Поэтому думал что зависит от того какой раздел проверяется.
Поэтому даже не знаю что и сказать.

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

Tau_0
28-06-2016, 21:24
В принципе достаточно и дампов - видно что чекдиск внёс изменения. »

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

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

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

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

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

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

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

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

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

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

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

yab
28-06-2016, 21:51
А я вот никаких изменений не заметил…: »
Разве это неожиданно? :)
Это атрибут всегда должен быть резидентным и имя должно быть $MFT… »
А чекдиск считает что он может быть и не резидентным. Да и сама система, т.к. в противном случае том бы не открылся и до исправлений чекдиска.

Tau_0
28-06-2016, 23:30
и до исправлений чекдиска. »
Покажите в рапортах чекдиска, где есть хоть какая-то обмолвка об исравлениях хоть чего-нибудь...

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

Tau_0
29-06-2016, 00:25
например, можно затереть зеркало, и оно самовосстановится. И без всяких чекдисков. »
Так ведь самовосстановится без чекдиска...

yab
29-06-2016, 00:34
Так ведь самовосстановится без чекдиска... »
Наметился прогресс?

Tau_0
29-06-2016, 01:35
Наметился прогресс? »
Милай ты мой..., ещё несколько лет назад я удалял некоторые некритичные метафайлы типы битовой карты или $BadClus. Система их спокойно восстаналивала без чекдиска...

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

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

yab
29-06-2016, 02:36
то имя файловой записи не является обязателным типом... »
Ты уж определись является или нет. :)
Сам себе противоречишь и бубнишь какую то ересь.
Может лучше промолчать, или вообще изучить то, что предложил?

Tau_0
29-06-2016, 18:47
Сам себе противоречишь и бубнишь какую то ересь. »

Умник или чванливый невежа...: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)

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

Tau_0
30-06-2016, 01:19
30-й атрибут в записи есть - просто он описан немного в другом виде. »
Зри картику в форматном просмотре файловой записи ID=0. --- Покаж мя, где твоя увидела Attribute type = 30...???...




© OSzone.net 2001-2012